continued: Common-VFS proposal

[nf2]

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",
>"list documents") 
>  
>
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  [1] like (Gnome-VFS) [2], 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[3]. 
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.

[1] POSIX style: Using open-read/write-close functions and handles  (I 
called it "synchronous Interface", maybe "Streaming Interface" would be 
clearer).

[2] 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).

[3] I think Gnome-VFS does it that way, but i'm still a bit confused 
about the AcsyncDaemon Interface in GNOME_VFS_Daemon.idl.

Regards,

Norbert