Time to stop painting...

[Ryan C. Gordon]

Half the skill required to be a painter is to know when to _stop_ painting.

I've decided I'm pleased with PhysicsFS 0.1.9 as a release candidate.

Barring objections, 0.1.9 will become 1.0.0 in a few days. At that time, 
I'll begin a new development branch, 1.1.0, and only minor bugfixes will 
be applied to the 1.0.0 source tree. If there are any outstanding bugs 
that have been bothering you in 0.1.9, now is the time to mention them.

The only thing I really expect to be changing before 1.0 is perhaps a 
build target that is broken (i.e. - MacOS 9 built with CodeWarrior or 
OS/2 haven't been tried recently and might need updates to their build 
systems), but other comments are welcome.

Once 1.0.0 is released, some new development can/will hit CVS. Notably:
- The internals are getting ripped up a little to reduce malloc() 
pressure and heap fragmentation, make things a little cleaner and more 
efficient. This wouldn't change the external API at all, but it could 
introduce subtle bugs that need to be weeded out...and I don't want to 
delay 1.0.0 for that.
- Mount points. More than one person has written to request this, and it 
makes sense for "sandboxing" mods...without this, downloadable content 
can possibly override an application's data files, or at least muddy the 
waters. If you can force a downloaded archive's files to be exposed at 
/mods/modname/[...] instead of /[...], then it's mucch more 
straightforward to sandbox a given mod. This also lets multiple mods 
which contain identical file names coexist, even if overriding your 
default content isn't an issue. This can be added to PhysFS as a new 
function, but without breaking backwards compatibility 
(PHYSFS_addToSearchPath() would effectively be mounting the archive at "/").
- mmap() support in posix.c/unix.c for added i/o efficiency. Perhaps the 
equivalent in win32.c with VirtualAlloc() or whatever.
- Someone suggested wrapping the win32 registry in PhysFS...a 
platform-independent way to read/write config variables 
(~/.appname/config.ini on Unix, etc). I don't know if this is going into 
PhysFS itself, but it'll at least end up in a small public-domain source 
file in the contrib directory that interested developers can just copy 
into their projects.
- New archivers?
- New platforms?
- New language bindings?
- Other stuff.

--ryan.