[physfs] 2.0 wishlist...

[Adam D. Moss]

Hi!  Just some feedback as a heavy physfs user.  I'll go with
an arbitrary five star rating:

Ryan C. Gordon wrote:
> - Move to Subversion from CVS. This is overdue.

[***  ] svn makes me happy... but this wouldn't much affect
physfs's usability for me.

> - Add "mount points":

[*    ] sounds nice, but I wouldn't have a use for it a.t.m.

> - 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

[**   ] again sounds nice, but I can't immediately find a use for it.

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

[**   ] Nice, but I'm not really suffering with things how they are.

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

[**   ] nice-to-have

> - 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.

[*    ] nice-to-have (but I don't think I'd use it)

> - 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.

[***  ] I'd probably find some good uses for this (as you say, tools).
Could this be as simple as allowing the adding of '/' into physfs's
searchpath?  Ugh, but then of course some systems' device structure isn't
really a tree.  But I'd DEFINITELY like to be able to continue to
address files and perform file IO in a consistant plat-independant
manner, that being a large attraction of using physfs for tools (and
everything).

I wouldn't like to see the security model relaxed by default though;
as well as the fairly effective I/O sandboxing it offers, having to
operate within physfs's constraints does force one to plan one's
on-disk tree structure with more care (which is good).

Here's my pet addition:

[*****] Non-blocking I/O

Full-on async-I/O is probably overkill/overengineering for physfs's
remit (not that it wouldn't be nice!), but non-blocking I/O would be
an adequate basis for some nice things like speculative pulling-in
of level and texture data without causing unavoidable troughs in the
frame rate.

Thanks,
--Adam