[physfs] PhysicsFS 2.1 roadmap...

Ryan C. Gordon icculus at icculus.org
Sat Mar 28 22:18:56 EDT 2009


So now that 2.0 is the stable branch, it's time to decide some things 
about a new development branch.

Here's my TODO list.

- Rearrange the source directory.
- Cleanup FIXMEs.
- Add an API to find the "pref path" ... this is the directory where an 
app's configuration data is supposed to go...which is usually somewhere 
under the user directory, but not always. As it is platform-dependent, 
platform-version dependent and sometimes even user-dependent, this 
should be handled by the library and not the app.
- Abstract out the file i/o, and let applications supply 
implementations. This will allow apps to do things where they control 
the i/o at the byte level: archives in a memory buffer, archives in 
archives, encrypted archives, etc.
- Archives formats provided by the implementation.
- Write support for various archives. I haven't decided how to do this 
yet, but I'd like to.
- New archive types: .tar(.bz2|.gz), maybe .rar, other requests.
- Implement Unicode support for OS/2.
- Dump the makeos2.cmd script and use CMake on that platform (OpenWatcom?)
- Replace the existing error strings with something more 
flexible...right now, you have to pick a translation at compile time, 
which isn't too useful. It might be nice to have real error codes for 
apps instead of just error messages for humans, too.
- UTF-16 support. 2.0.0 only handles UCS-2, which is most of the work, 
but leaves out the "surrogate" codepoints. UTF-16 is a superset of 
UCS-2. Older Windows using Unicode used UCS-2, newer Windows platforms 
use UTF-16.
- Add an API to expose a file's extended attributes to the application?
- Deprecate PHYSFS_setSaneConfig(). It really should have been in the 
extras directory.
- Clean up the sources to match my ever-changing coding style.  :)

I'm taking requests from the peanut gallery: if you want to see 
something added/removed/changed in PhysicsFS, please speak up now, as 
the development branch can change the API in any way that makes sense.

--ryan.



More information about the physfs mailing list