[physfs] 2.0 wishlist...
Adam D. Moss
adam at gimp.org
Tue Sep 21 04:13:02 EDT 2004
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
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
More information about the physfs