Re: [boost] Re: Re: Re: extending boost::io

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-10-14 11:13:15

On Thu, 14 Oct 2004 09:25:08 -0600, Jonathan Turkanis wrote
> "Israel Fdez. Cabrera" <israel_at_[hidden]> wrote in message
> news:416DA364.2070107_at_segurmatica.com...
> > Jonathan Turkanis wrote:
> 
> > >The library needs to be cleaned up a lot before I can post it. If there is
> > >sufficient interest, I'll try to do it, but it would be at least a couple
> months
> > >from now, since I'll be busy trying to get iostreams ready for 1.33.
> > >
> > >
> > There is interest in the library, and I'm sure some other have interest
> > too. iostream is a great step ahead in C++, but with this kind of
> > support for compressed, OLE files and maybe more, it will be just
> > fantastic. It is fantastic to compress and decompress file in just 6
> > lines of code dont you think? :)
> 
> Yes, but I'm aiming for 4. ;-)
> 
> > Let's think I have to use other library, i.e. libgsf  from GNU. I have
> > the following doubt. I have a single OLE file, I open() it using a
> > boost::io stream, how more than one stream can be obtained from a single
> > one, taking this OLE file has more than one contained file?
> 
> For each type of archive (zip, tar, ole) you have to have a module 
> (an 'archive_handler') that knows the format and can extract the 
> information. The appropriate handler is called automatically when 
> someone wants to read an entry for an archive of a particular type. 
> To implement a handler, however, you need to write code which either 
> completely understands the file format in question or delegates that 
> responsibility to an outside library.

Well, since you guys are thinking down this path, what I've wanted to try is
to have these "multi-stream" files export a boost::filesystem directory
iterator for the file index and then provide an interface to open an
individual 'sub-file' as an fstream. Of course you need the add and remove
file interfaces as well to really get control over the archive contents.

I think this may have radical impact on boost::filesystem in that this would
be a clear case where we want 2 file system implementations available at
runtime which is not really supported right now.

Jeff