continued: Common-VFS proposal

[Havoc Pennington]

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

NFS has *horrible* semantics for GUI apps (things just lock up, with no
progress indication, no way to cancel, and no way to know how much work
is left or what's happening).

Also, you can't *really* have POSIX semantics with the backends like
http etc.; because they involve multiple system calls and generally lots
more work with lots fewer guarantees than the POSIX APIs make.

There are also lots of backends that simply don't support parts of the
POSIX APIs, and it's much nicer to be able to query this in advance
instead of an ENOSYS style approach.

If you're talking the POSIX APIs *specifically* (as opposed to POSIX-
like) then you get other problems too, such as errno. error codes lead
to appallingly bad error messages. You need exceptions, or C emulations
of exceptions such as GError.

There's no value at all to being POSIX-like, because 1) mounting a
userspace VFS in the kernel is a really bad idea (see above about
semantic guarantees) and 2) the POSIX API is completely inconvenient and
doesn't do what most GUI apps want to do.

Visible threads in the API are bad, because neither GTK+ nor KDE are
very thread-friendly. gnome-vfs has threads behind the scenes only.

Finally, there are a bunch of APIs that should be virtualized according
to VFS module that are not in POSIX, such as trashcan and MIME.

Havoc