Updated.

icculus · Mar 25, 2002 · 255322c · 255322c
1 parent 51b65e1
commit 255322c
Show file tree

Hide file tree

Showing 2 changed files with 45 additions and 6 deletions.
diff --git a/CHANGELOG b/CHANGELOG
@@ -74,7 +74,9 @@
            improvements by Gregory S. Read. Added PHYSFS_[us]int(8|16|32)
            types...this breaks binary compatibility with previous PhysicsFS
            releases! Added platform specific i/o functions, so we don't have
-           to rely on stdio anymore.
+           to rely on stdio anymore. Updated TODO with my comments on the
+           physfs mailing list. 1.0, here we come!  Tons of other fixes and
+           enhancements.
 
 --ryan. (icculus@clutteredmind.org)
 

diff --git a/TODO b/TODO
@@ -1,17 +1,54 @@
 Stuff that needs to be done and wishlist:
 
-- autoconf?
+These are in no particular order. A 1.0 release is reliant on doing most of
+ this stuff. Some might be dupes, some might be done already.
+
+- autoconf support?
 - update the Makefile so that Cygwin can generate a DLL. The entire codebase
   compiles under Cygwin otherwise.
 - Hmm...we can determine the actual CD-ROM drives under Win32, but how do you
   decide that there's no disc in the drive?
 - MacOS (Classic and X) support.
-- Move the integer types to something abstract. uint32, etc.
 - Platform-specific functions/macros to handle byte ordering.
 - A PHYSFS_readUint32(), _readSint32(), etc API.
-- Ditch the "standard" i/o routines (fopen() and friends) and move this into
-  the platform drivers.
+- Patch the zlib used on win32 to 1.1.4.
+- Switch the CHANGELOG to list newest changes first.
+- Write manpages, preferrably generated from some javadoc-style solution
+  so we can make HTML versions etc from the same data.
+- Make internal code respect the new typedefs (PHYSFS_?int??).
+- Byte order API; just something simple like:
+    __EXPORT__ PHYSFS_uint16 PHYSFS_swapBE16(PHYSFS_uint16 val);
+    __EXPORT__ PHYSFS_uint16 PHYSFS_swapLE16(PHYSFS_uint16 val);
 
-// end of TODO ...
+   (these can be macros. The hard part is determining the architecture at
+    compile time, and whether a given platform offers accelerated
+    conversion macros already. We can probably jack this from SDL, too.)
+- Make win32.c respect the more strict filesystem layout enforced by
+  Win2000 and later.
+- Improve ZIP_seek() (archivers/zip.c)
+- entry_is_symlink() and version_does_symlinks() in zip.c have byte-order bugs.
+- Actually, the zipfile driver could use a lot of tweaking. Please look
+  through it.
+- Abstract out the use of stdio. It's not as "std" as I would like, in my
+  experience. Add code to the platform drivers to open, read, write, seek,
+  tell, etc on an abstract data type that is opaque outside the individual
+  platform drivers, so that dir.c has a unified codebase that talks to this
+  internal abstraction layer. This opaque data type can be a FILE * on unix,
+  and a HANDLE on win32, etc...
+- Other archivers: perhaps tar(.gz|.bz2), RPM, etc. These are less
+  important, since streaming archives aren't of much value to games (which
+  is why zipfiles are king: random access), but it could have uses for, say,
+  an installer/updater. I thought it might be neat to have MBOX and Maildir
+  support so that both "archives" look identical to an application; might be
+  nice for an email program. That's blue sky, unless someone wants to tackle
+  it.
+- Look for FIXMEs (many marked with "!!!" in comments).
+- Port to BeOS (might work already? Will work for sure with autoconf support)
+- Port to MacOS Classic (needs a platform driver, byte order fixes mentioned)
+- Port to MacOS X (specifically, make Project Builder files; unix.c should
+  work with it as-is. Might compile as-is with the current Makefile, byte
+  ordering fixes mentioned).
+- Probably other stuff. Requests and recommendations are welcome.
 
+// end of TODO ...