Excellent ideas by Christoph Nelles, I would like to second all of those.<br><br>However, I would like to add:<br>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?)<br>
<br><div class="gmail_quote">2010/1/26 Indy Sams <span dir="ltr"><<a href="mailto:indy@driftsolutions.com">indy@driftsolutions.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
<br>
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.<br>
<br>
#4 would hopefully be easy to implement too if there are any free ISO9660 libraries out there.<br>
<br>
Tuesday, January 26, 2010, 3:57:02 PM, you wrote:<br>
<br>
CN> Hello Ryan,<br>
CN> hello folks,<br>
<br>
CN> i have some proposals for physfs:<br>
CN> 1) A function PHYSFS_getFileSize() for getting the file size avoiding<br>
CN> the need to open a file before.<br>
CN> 2) Using error codes instead of error messages<br>
CN> 3) Plugin system for the archive handlers<br>
CN> 4) Support for ISO images<br>
<br>
CN> Rationale:<br>
CN> 1) Currently, if you want to know the size of a file, you have to open<br>
CN> the file and call PHYSFS_fileLength() and close the file. File<br>
CN> opening/closing may be quite expensive and a short cut function for<br>
CN> getting the file size from the metadata may be faster/handier. In the<br>
CN> case this info cannot be obtained from metadata -1 could still be<br>
CN> returned or a fallback for open/seek/tell/close could be performed. The<br>
CN> only big problem i see is that the reported file size on files currently<br>
CN> being written to may vary.<br>
<br>
CN> 2) A numeric error code is easier to process in error handling than a<br>
CN> message string. A number/constant should not change while the<br>
CN> corresponding error message may change, perhaps due to localization or<br>
CN> spelling errors. Currently there are 6 languages available. Instead of<br>
CN> storing a pointer to the string, an error code may be stored and made<br>
CN> available, without necessarily breaking te current API. Proposed<br>
CN> functions: PHYSFS_getLastErrorCode(), PHYSFS_getErrorMessage(code),<br>
CN> PHYSFS_getErrorMessageLocalized(code,lang) or something similar.<br>
CN> PHYSFS_getLastError() may become a wrapper for<br>
CN> PHYSFS_getErrorMessage(PHYSFS_getLastErrorCode()).<br>
<br>
CN> 3) Using a VFS is really nice, but for some uncommon container files it<br>
CN> may be necessary for the using application to plug its archive handlers<br>
CN> into physfs during runtime. So it will be possible to continue using a<br>
CN> vanilla physfs shared object/DLL/etc with custom archive handlers from<br>
CN> the application. This requires the supported archive handlers array to<br>
CN> be dynamic. One user defined entry may be sufficient. A function for<br>
CN> special mounting may be needed too for "archives" not based on an<br>
CN> underlying file.<br>
<br>
CN> Personally I am thinking about a way to compile files directly into the<br>
CN> application binary. A resource identifier is nice, but unified access<br>
CN> via a VFS is nicer. Or something like a simple network file system for<br>
CN> streaming content from a server to a client.<br>
<br>
CN> 4) Although an ISO can be unpacked easily, this may be useful for<br>
CN> reimplementations of old games and it's a quite common container.<br>
CN> Perhaps a candidate for #3 ;)<br>
<br>
CN> I will gladly implement or help implementing those features, but i have<br>
CN> only experience and access on/to Linux & Windows.<br>
<br>
CN> Please give me a feedback.<br>
<br>
Best regards,<br>
Indy Sams<br>
mailto:<a href="mailto:indy@driftsolutions.com">indy@driftsolutions.com</a><br>
<br>
P.S. This is what part of the alphabet would look like if Q & R were eliminated.<br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
physfs mailing list<br>
<a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
<a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
</div></div></blockquote></div><br>