continued: Common-VFS proposal

mETz mETz81 at
Mon Jan 24 16:44:37 GMT 2005

On Montag Januar 24 2005 17:16, Havoc Pennington wrote:
> 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

Because not everybody likes Gnome-VFS? :)

> > 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") 

And that's the reason why KIO sucks. It just has upload and download functions 
(and of course more stuff, but that's not interesting right now). What is 
actually needed for faster links like smb/nfs (and sometimes ftp) is a kind 
of normal file API, which is probably what gnome-vfs does (I never looked at 
gnome, I'm too scared by plain gtk-code already).

> 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.

But I don't want to query stuff in my app, I just want to use it! If the 
ioslave doesn't implement seeking it has to download the whole file and let 
me work on the local version, I don't want to do that myself (otherwise I 
could do the rest manually too) :)

Bye, Stefan aka mETz

More information about the kde-core-devel mailing list