Re: [GNOME VFS] Re: GUADEC Issue discussion summary ...

[Maciej Stachowiak <mjs eazel com>]

ERDI Gergo <cactus cactus rulez org> writes:

> 	vfs:http://foo.bar/baz/quux.gnumeric.gz#gzip!Sheet1 [1]
> However, it would be made up of two parts: 
> http://foo.bar/baz/quux.gnumeric.gz#gzip and Sheet1. Ideally, it should be
> made of three parts: http://foo/quux.gnum, gzip, and Sheet1.
> `OK this is just nitpicking' No it's not. Imagine if someone wanted to
> store gzip'd data inside a bonobo-conf field. You would want to read/write
> conf:/Applications/MyApp/MyBigSetting via the gzip moniker. But you
> couldn't do that because there is no separate gzip moniker, only the
> gnome-vfs moniker which doesn't work on `entities' that come from outside
> gnome-vfs land.

OK, so the requirement would be for gnome-vfs to expose the
filter-oriented modules (gzip, tar, etc) in a way that lets you apply
them to an arbitrary data stream and not just chain them to other
gnome-vfs modules. I think it should not be hard to design an API like
that and it doesn't necessarily require depending on bonobo. At the
same time, the vfs moniker could do a fast-path optimization for
things like http://foo.bar/baz/quux.gnumeric.gz#gzip: where it knows
it can handle multiple parts of the chain directly.

BTW, I don't think you really want "vfs:" in a moniker ever, anyway;
the moniker should be about where the data comes from, not the
mechanism used to retrieve it. I hope that was just for the sake of
example.


-- 
Maciej Stachowiak
Eazel, Inc.