[physfs] 2.0 wishlist...

[Ryan C. Gordon]

> > - Expose the archiver registration mechanism
> Would be nice, but not vital.

Yeah, it's a low-priority, would-be-nice thing. It's possible it might
not happen, since that means locking down the internal API to some
degree, though. I just get annoyed every time I look at those #ifdefs
for all the archivers in physfs.c...

> Do you want to use alloca(), or just have a stack-like scratchpad or 
> hardcoded heap provided by the app?

Depends...I think a lot of the crap is basic string handling and moving
small blocks around...good candidates for alloca(). The things that
aren't will be moving to the allocation hook, which can be handled as
scratch memory, etc.

> > - 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 REALLY want this a lot, as you know.

That's why it's on the Wishlist.  :)

We need to talk about this more. Would a model where you turn off
security checks be sufficient? Do you need a PHYSFS_file handle but
otherwise don't care about search and write paths? Can we get away with
a wrapper in the extras dir that provides functionality layered on top
of the 1.0 API, etc...

I don't want to do this twice because we find the first way limiting,
and this is the only part of the plan I'm pretty hazy on right now...

> Yes, 1.0 is teh bomb.  I'm not sure if 2.0's changes are 2.0-worthy, 
> more like a 1.5, but that's semantics =)

Mostly because it gives me license to add entry points. I intend to not
break binary compatibility with 1.0 if at all possible, though.

--ryan.