Re: Plans for gnome-vfs replacement
- From: Alexander Larsson <alexl redhat com>
- To: Magnus Bergman <magnus bergman observer net>
- Cc: gnome-vfs-list gnome org
- Subject: Re: Plans for gnome-vfs replacement
- Date: Mon, 02 Oct 2006 09:48:55 +0200
On Fri, 2006-09-29 at 17:52 +0200, Magnus Bergman wrote:
> > > You're only mentioning the low-level stream parts here, but is
> > > there any previous work of a filesystem/virtual folder API apart
> > > from POSIX which could be used as a comparision?
> > >
> > > Do you know what win32, OS/X, Java, .NET, etc provide in this area?
> > I like the java.io.File class which does the pathname abstraction.
> > Win32 has something called "Shell extensions" which are similar to
> > the whole VFS layer. Other than that there is not a lot of previous
> > art.
> I have a few years of experience with a commercial VFS implementation
> from Verity . I won't go into details (it is actually way too
> complicated) but it kind of works like this:
> Backends can provide one of a few APIs. The one I find most usefull is
> the streaming API. Streams are not necessarily identified by
> filenames, any type of string can be used (and in some way it gets
> mapped to a backend which knows how to interpret it). Then you open a
> stream using this you specify which metadata you are interested in.
> There are some standard stuff you can add to a bitfield (author,
> filename, mimetype etc), but you can also specify custom fields which
> are often specific to the backend. Everything is then transfered as
> packages, containing either one metadata item or a chunk of the
> contents. You can request seeks of the stream but they might be denied,
> delayed or inexact (and the only way to tell is by the offset in the
> coming chunks). It can also have backends which take input streams
> (which can be used to access files in an archive or to convert files on
> the fly). (I guess this is also kind of similar to GStreamer, but less
> advenced since GStreamer can do a lot more like can relink the
> stream dynamically.)
> The good thing is that it's very flexible. Things are usually done in
> the most efficient way. But the user of the API must take on a lot of
> the responsibility so it's all but a beautiful thing.
Interesting. It seems pretty similar to what I'm thinking, but a bit
more taxing on the API user and a bit more lenient for the backend
implementation (which sometimes can lead to more efficient
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's an ungodly guitar-strumming rock star who knows the secret of the alien
invasion. She's a disco-crazy impetuous college professor with the power to
bend men's minds. They fight crime!
[Date Prev][Date Next
] [Thread Prev][Thread Next