continued: Common-VFS proposal

[Havoc Pennington]

On Mon, 2005-01-24 at 14:16 +0100, nf2 wrote:
> The thing i'm proposing on my page (plugging the front-end of Gnome-VFS 
> into the backend of KIO) is a kind of a "shared backend" approach.
> 
>  From concept a "shared backend" would always be a fully equipped VFS 
> library with middleware, daemon and modules. It just needs all that 
> stuff to work (Perhaps with some little bits missing in the client part).
> 
> So why not use Gnome-VFS as "shared backend" in KIO and start 
> redirecting protocols one by one as soon as the qualitiy of a Gnome-VFS 
> Module matches the KIO one (the migration you suggest). Might be less 
> work than writing a complete third VFS.

In my view that would not be robust enough (or simple enough).

gnome-vfs has one huge design flaw, which is that it looks like
the POSIX file API. It should instead be a very very simple 
core interface ("get entire document", "put entire document",
"list documents") plus a facility for backends to implement
additional features that can be checked for at runtime.
e.g. you should be able to say "does it support unix 
style permissions?" and if so an interface 
UnixPermissions is available with a chmod method.
Just the usual queryInterface() pattern.

This has several effects, one of them is that the 
whole system is extensible for future features we want
to export, another is that writing a simple backend is 
a lot easier (and backends don't have to be wedged into
UNIX semantics). It also sets us up to be cross-platform 
UNIX/Linux/Windows, which would do wonders for adoption.

Yes, you can base some of the code on existing kio/gnomevfs
code, but I do think there's a basic design issue to be 
fixed.

Havoc