continued: Common-VFS proposal
nf2 at scheinwelt.at
Tue Jan 25 16:38:18 EET 2005
Havoc Pennington wrote:
>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",
That's not a design flaw - that's one of the examples where the
Gnome-VFS design is correct (IMO).
A shared backend in KIO style (async get/put only) won't work. The
reason is that with async get/put you give up "flow-control".
With the consequence that you can easily wrap a KIO style system (async
get/put only) around a POSIX style system  like (Gnome-VFS) , but
not the other way round. Therfore a shared backend *has* to go the POSIX
way (because Gnome-VFS did it).
Async behavior can be easily achieved with threads in the VFS client.
It's an "add on" and not a core feature of a VFS.
Doing it the POSIX way allows to run modules in the client process (even
in the same thread when not using an async wrapper). Only certain
modules with advanced session handling & synchronizing access need to
run in a kind of daemon.
 POSIX style: Using open-read/write-close functions and handles (I
called it "synchronous Interface", maybe "Streaming Interface" would be
 In my KIO->Gnome-VFS ioslave, for instance, i am using the POSIX
style interface of Gnome-VFS (And not the async interface). This
prevents main loop problems and creating another IPC or thread bridge
(for most protocols).
 I think Gnome-VFS does it that way, but i'm still a bit confused
about the AcsyncDaemon Interface in GNOME_VFS_Daemon.idl.
More information about the xdg