[physfs] 2.0 wishlist...

[Tree]

Hi,

Physfs 1.0 was indeed great for our project, it integrated really easily 
with the dependencies we used, and modding to support it was easy in things 
like freetype and libjpeg.

Following Adam Moss' starring system, these are how relevant they are to my 
current project which uses physfs:

> - Move to Subversion from CVS. This is overdue.

[***] SVN is definitely the way to go, but not going to effect the project

> - Add "mount points":

[***] This would be useful to us if it existed. We use multiple track files 
(Java jar files), which include code and data. At the moment, we have to 
modify the search path manually for work around potential path conflicts. 
Having a clean way to this would be preferred, especially when our track 
files start to share data.

> - Expose the archiver registration mechanism to the outside world, so
> you can optionally plug in support for a format at runtime. Relatively
> easy to do, I think, would clean up the guts of physfs a little

[*] Cleaner so it's good, but not useful to us, as we know we just need Dir 
and Zip handlers.

> - Reduce malloc() pressure. We allocate way too much small and temporary
> shit that is better suited for alloca().

[**] Not noticed any external problems either.

> - Set up a mechanism for file enumeration that employs a callback into
> the application to avoid allocating a throwaway list when possible.

[***] Again something which we would us if it existed.

> - Allow the application to provide allocation services (with the default
> to call malloc() directly from physfs). This is extremely useful for,
> say, a PalmOS port.

[*] Not needed by us

> - Find some way to relax or remove the security model so apps can have
> roughly the same codepath for the game itself and external tools. I
> think this probably needs a little more discussion.

[***] This has been an issue with our editors, but we have a work around or 
editing the WriteDir when we need to.

> Non-blocking IO

[****] This would be probably be the thing I'd like to see most of the 
suggestions raised. At the moment we load all our data at the start because 
we have to, as our tracks get larger so will loading times, so some sort of 
async loading would be very handy.

Addition (All I can think off to be honest):

Remove bundled zlib and use standard distro. I can't see any diffs except 
the use of the Z_PREFIX usage.

[**] Not important, but cleaner. Our project uses zlib as a dll shared 
between several other libs (libpng, etc), so this is already how we already 
use physfs. I prefer this to staticly linking in several places.

fscanf and fprintf support

[**] Again something we already have externally, because I added it to a 
modified abs-file.h we use. Because we used them a lot with text files prior 
to using physfs, we figured adding support to physfs was fair enough. I've 
attached the abstraction file we use, they are a quick hacky job, I'm sure 
they are better ways to do it. (The vsscanf method is missing under windows 
so had to be botched, and a better PC specific asm hack is on the web but 
this one is cross-platform.)

And that's it for now,

Tree
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: FileHandling.h
URL: <http://icculus.org/pipermail/physfs/attachments/20040921/a03a6741/attachment.diff>