continued: Common-VFS proposal

[Sean Middleditch]

On Tue, 2005-01-25 at 15:38 +0100, nf2 wrote:
> 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).

It's horrendously wrong.  The POSIX API is broken from an application
developer's standpoint.  As a developer, I never want to think in terms
of "read X bytes" and "write X bytes", nor do I want to have the open
call perform a wide variety of different tasks (opening files, creating
files, making lock files, etc.).

The API should be designed around what applications want to do, and the
details is something that can be worked out under the hood.  The read
and write calls need to stay for various obvious reasons, but things
like the open call can be split into several operations, and more calls
can be added for things that the POSIX API has no equivalent for, like
file moving.

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

No, a shared backend that is designed to magically plug into the
existing system is required to keep the same broken interface, but a new
VFS system can get rid of the mistakes of the current implementations.
Which is one reason I'm advocating a newer system.

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

You can tear out my lungs before you force a threaded library on
me.  ;-)

Libraries should be able to work with threaded apps, but they should not
go around creating their own threads.

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

Except for the security issues of letting all the apps access the user's
login credentials...

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

POSIX is async capable.

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

Having to ignore important features due to the limitations of bridging
the two systems is another great example of why bridging them is the
wrong way to solve the common VFS problem.

> 
> [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
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>