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&#39;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">&lt;<a href="mailto:indy@driftsolutions.com">indy@driftsolutions.com</a>&gt;</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&gt; Hello Ryan,<br>
CN&gt; hello folks,<br>
<br>
CN&gt; i have some proposals for physfs:<br>
CN&gt; 1) A function PHYSFS_getFileSize() for getting the file size avoiding<br>
CN&gt; the need to open a file before.<br>
CN&gt; 2) Using error codes instead of error messages<br>
CN&gt; 3) Plugin system for the archive handlers<br>
CN&gt; 4) Support for ISO images<br>
<br>
CN&gt; Rationale:<br>
CN&gt; 1) Currently, if you want to know the size of a file, you have to open<br>
CN&gt; the file and call PHYSFS_fileLength() and close the file. File<br>
CN&gt; opening/closing may be quite expensive and a short cut function for<br>
CN&gt; getting the file size from the metadata may be faster/handier. In the<br>
CN&gt; case this info cannot be obtained from metadata -1 could still be<br>
CN&gt; returned or a fallback for open/seek/tell/close could be performed. The<br>
CN&gt; only big problem i see is that the reported file size on files currently<br>
CN&gt; being written to may vary.<br>
<br>
CN&gt; 2) A numeric error code is easier to process in error handling than a<br>
CN&gt; message string. A number/constant should not change while the<br>
CN&gt; corresponding error message may change, perhaps due to localization or<br>
CN&gt; spelling errors. Currently there are 6 languages available. Instead of<br>
CN&gt; storing a pointer to the string, an error code may be stored and made<br>
CN&gt; available, without necessarily breaking te current API. Proposed<br>
CN&gt; functions: PHYSFS_getLastErrorCode(), PHYSFS_getErrorMessage(code),<br>
CN&gt; PHYSFS_getErrorMessageLocalized(code,lang) or something similar.<br>
CN&gt; PHYSFS_getLastError() may become a wrapper for<br>
CN&gt; PHYSFS_getErrorMessage(PHYSFS_getLastErrorCode()).<br>
<br>
CN&gt; 3) Using a VFS is really nice, but for some uncommon container files it<br>
CN&gt; may be necessary for the using application to plug its archive handlers<br>
CN&gt; into physfs during runtime. So it will be possible to continue using a<br>
CN&gt; vanilla physfs shared object/DLL/etc with custom archive handlers from<br>
CN&gt; the application. This requires the supported archive handlers array to<br>
CN&gt; be dynamic. One user defined entry may be sufficient. A function for<br>
CN&gt; special mounting may be needed too for &quot;archives&quot; not based on an<br>
CN&gt; underlying file.<br>
<br>
CN&gt; Personally I am thinking about a way to compile files directly into the<br>
CN&gt; application binary. A resource identifier is nice, but unified access<br>
CN&gt; via a VFS is nicer. Or something like a simple network file system for<br>
CN&gt; streaming content from a server to a client.<br>
<br>
CN&gt; 4) Although an ISO can be unpacked easily, this may be useful for<br>
CN&gt; reimplementations of old games and it&#39;s a quite common container.<br>
CN&gt; Perhaps a candidate for #3 ;)<br>
<br>
CN&gt; I will gladly implement or help implementing those features, but i have<br>
CN&gt; only experience and access on/to Linux &amp; Windows.<br>
<br>
CN&gt; 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 &amp; 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>