Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-12-09 13:41:06


Korcan Hussein wrote:
> Just a thought if boost file-system could be user-configurable with
> boost iostreams library we could have a nice, clean API for virtual
> file-systems (VFS) not just for the OS file-system.

> For example the other day an associate of mine wanted to be able to
> read/write/etc to a zip file like a OS file-system, he couldn't use
> boost iostream's zip filter since it doesn't apparently provide that
> kind of behaviour/abstraction but boost file-system does provide that
> kind of abstraction/behaviour the only problem is it's pretty much
> tied to working with OS file-systems only as far as i'm aware.

I think this is a great idea. In fact, the original Iostreams code was a
component of a larger library which provided a uniform interface for
hierarchical containers of data that behave like filesystems. Among other
things, there was support for zip archives and OLE compound documents on
windows. It also allowed nesting of filesystems and addressing files within
nested filesystems using the !/ notation empolyed by Sun's jar: protocal. E.g.,
ole:http://example.com/archive.ole!/hello.txt.

The original library was too heavyweight and monolithic for submission to boost;
for example, it required thread support and provided automatic caching. However,
I've been planning on eventually producing a version that could be submitted to
boost.

There's also been talk on this list of extending Boost.Filesystem to add this
functionailty. However, I'm not sure this is possible in the foreseeable future
because it could interfere with the standardization of Boost.Filesystem which is
now underway. I think it would be best to start a new library.

I'm really too busy to do this right now (I'm trying to give a priority to the
proposed Boost.Interfaces whenever I have free time). But if someone else wants
to take the lead, I'd be happy to help.

Best Regards,

-- 
Jonathan Turkanis
www.kangaroologic.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk