[physfs] Wishlist

[Indy Sams]

Hello,

	As for item 1), I had made a patch implementing PHYSFS_stat() which worked the same way as stat() does and gave the size, modification time, etc. I think I emailed it in a long time ago but never heard anything back about it.

	#4 would hopefully be easy to implement too if there are any free ISO9660 libraries out there.

Tuesday, January 26, 2010, 3:57:02 PM, you wrote:

CN> Hello Ryan,
CN> hello folks,

CN> i have some proposals for physfs:
CN> 1) A function PHYSFS_getFileSize() for getting the file size avoiding
CN> the need to open a file before.
CN> 2) Using error codes instead of error messages
CN> 3) Plugin system for the archive handlers
CN> 4) Support for ISO images

CN> Rationale:
CN> 1) Currently, if you want to know the size of a file, you have to open
CN> the file and call PHYSFS_fileLength() and close the file. File
CN> opening/closing may be quite expensive and a short cut function for
CN> getting the file size from the metadata may be faster/handier. In the
CN> case this info cannot be obtained from metadata -1 could still be
CN> returned or a fallback for open/seek/tell/close could be performed. The
CN> only big problem i see is that the reported file size on files currently
CN> being written to may vary.

CN> 2) A numeric error code is easier to process in error handling than a
CN> message string. A number/constant should not change while the
CN> corresponding error message may change, perhaps due to localization or
CN> spelling errors. Currently there are 6 languages available. Instead of
CN> storing a pointer to the string, an error code may be stored and made
CN> available, without necessarily breaking te current API. Proposed
CN> functions: PHYSFS_getLastErrorCode(), PHYSFS_getErrorMessage(code),
CN> PHYSFS_getErrorMessageLocalized(code,lang) or something similar.
CN> PHYSFS_getLastError() may become a wrapper for
CN> PHYSFS_getErrorMessage(PHYSFS_getLastErrorCode()).

CN> 3) Using a VFS is really nice, but for some uncommon container files it
CN> may be necessary for the using application to plug its archive handlers
CN> into physfs during runtime. So it will be possible to continue using a
CN> vanilla physfs shared object/DLL/etc with custom archive handlers from
CN> the application. This requires the supported archive handlers array to
CN> be dynamic. One user defined entry may be sufficient. A function for
CN> special mounting may be needed too for "archives" not based on an
CN> underlying file.

CN> Personally I am thinking about a way to compile files directly into the
CN> application binary. A resource identifier is nice, but unified access
CN> via a VFS is nicer. Or something like a simple network file system for
CN> streaming content from a server to a client.

CN> 4) Although an ISO can be unpacked easily, this may be useful for
CN> reimplementations of old games and it's a quite common container.
CN> Perhaps a candidate for #3 ;)

CN> I will gladly implement or help implementing those features, but i have
CN> only experience and access on/to Linux & Windows.

CN> Please give me a feedback.

Best regards,
 Indy Sams
 mailto:indy at driftsolutions.com

 P.S. This is what part of the alphabet would look like if Q & R were eliminated.