[physfs] Wishlist

[Tim Čas]

Excellent ideas by Christoph Nelles, I would like to second all of those.

However, I would like to add:
5) read/write access to files (there already is write access, why couldn't
same/similar method be used for R/W? What are the issues?)

2010/1/26 Indy Sams <indy at driftsolutions.com>

> 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.
>
> _______________________________________________
> physfs mailing list
> physfs at icculus.org
> http://icculus.org/mailman/listinfo/physfs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/physfs/attachments/20100127/0ece72b4/attachment.htm>