[physfs] PhysicsFS 2.1 roadmap...

Indy Sams indy at driftsolutions.com
Wed Apr 8 01:31:49 EDT 2009

Hello Gerry,

      I don't know about replace, but there are wrappers included that
      allow you to use PhysicsFS handles as RWOps.

Wednesday, April 8, 2009, 1:01:50 AM, you wrote:

GJ> Related to this (somewhat), and just for ideas..  I made a little
GJ> streaming library some time ago (because I also wanted to be able to
GJ> access in-memory buffers as streams, which current PhysFS doesn't
GJ> provide), tentatively named MIO, which simply treats everything as
GJ> streams. Streams could be plugged and chained together, so you could
GJ> read from an archive or disk, deflate, patch and calculate md5sum, all
GJ> with just one call to the read function (or even write it as well,
GJ> using copy), with everything done on the fly, only processing what's
GJ> needed.  For a little more efficient reading you could also plug in
GJ> buffers, etc.  I even toyed with using it as a primitive sound mixer =)

GJ> There was essentially two types of streams: Raw streams from some
GJ> specific source (disk, ram, etc), and transformation streams that took
GJ> other streams of any type as input and processed them in some way
GJ> (deflate, calculate things, etc).  Additionally, streams had
GJ> "properties", or specialized actions -- eg, a stream with the
GJ> 'Directory' property could be used to open new raw streams from inside
GJ> that stream with a call to the control function (more on that below).

GJ> The API for this was pretty simple. A stream-specific open function
GJ> would set up a stream structure with a minimum of three function
GJ> pointers, one each for read, write and control. Control was the
GJ> catch-all used for seeking, determining size, closing, opening from
GJ> directory, etc, usually implemented as a switch block with the
GJ> supported actions (perhaps this was a bit dense, but it made supporting
GJ> only those actions you wanted very easy).  There was also a system for
GJ> querying support for actions (so you didn't have to actually try
GJ> calling them to see if the were supported).  Streams also had an id
GJ> field and room for stream-specific data and the parent stream if any.
GJ> The MIO library was essentially a collection of some standard stream
GJ> handlers like this, tied together by a header with some prototypes
GJ> and inline functions to call the read, write and control function
GJ> pointers in a more user-friendly way.

GJ> Anyway, the project I made this *for* never got anywhere, but MIO
GJ> itself worked great.  Lightweight, extensible (you could perhaps argue
GJ> that the implementation was just some standard extensions..), and did
GJ> everything I wanted it to do.  So hey, it'd be nice to be able to do
GJ> something like this with PhysFS 3.0 .. =)  (Why I'm not just using MIO
GJ> myself?  .. well, I could I guess, but I see no reason to try to
GJ> compete with PhysFS if it's heading in that direction anyway.)

GJ> Oh also, how likely would you say it'd be for PhysFS to replace RWops
GJ> in SDL 1.3 and friends?  Just basic streams, with support for pulling in
GJ> the rest of PhysFS if you wanted to handle compressed data and such..
GJ> I'd guess extremely unlikely, but thought I'd at least air the idea
GJ> anyway =).  It'd be convenient to just have one stream wrapper to worry
GJ> about..

GJ> Blue sky,
GJ> - Gerry

GJ> Den Tue, 7 Apr 2009 16:59:15 +1000
GJ> skrev Anthony Cassidy <anthonytcassidy at hotmail.com>:
>> I don't really fit under the concept "peanut gallery", I am more a
>> "friendly lurker", I have been reading the mailing list for long
>> enough that I don't remember the original reason I joined.
>> But I have some thoughts about one of your ideas "New archive
>> types: .tar(.bz2|.gz),...", bzip2 and .gzip only compress a single
>> file (stream), which would need to be uncompressed then processed as
>> a tar file. libzip2 provides library functions to do that part, where
>> the gzip documentation says use zib. Where all this is going is that
>> both will need to be uncompressed then processed. Where for rar and
>> the like, the uncompression is part of the processing. If you support
>> tar.bz2 and tar.gz, then it would be good to be able to provide a
>> custom uncompression routine, which could be highjacked to do things
>> like unecryption instead.
>> tldr; If you are going to support tar.bz2 and tar.gz files, its
>> really processed (uncompressed) and the tar file is then read. It
>> would be nice to be able to provide custom processing routiens that
>> would allow for file encryption or downloading the file from an
>> external source.
>> Then this process could be applied to any archive type. Not sure how
>> useful this would be, but its just a thought.
>> -Anthony "Timmy" Cassidy
>> _________________________________________________________________
>> Looking for a fresh way to share photos? Get the new Windows Live
>> Messenger. http://download.live.com/
GJ> _______________________________________________
GJ> physfs mailing list
GJ> physfs at icculus.org
GJ> http://icculus.org/mailman/listinfo/physfs

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.

More information about the physfs mailing list