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".
>
> 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.
*footnotes snipped*
POSIX consists of a lot more than just open -> read|write -> close and
comes burdened with a lot of filesystem semantics that are a horrible,
horrible fit for a lot of networked (and other) file systems out there.
For 90% of applications, the simple get/put/list interface would be
entirely sufficient. For those areas where POSIX semantics modules
could easily provide "IPosix" interfaces or similar (even then, you
might want to break POSIX down into more than one interface). And
nothing says that a simple get/put/list interface has to be async.
Additionally, there are already areas in which gnome-vfs is not POSIX
compliant (if I'm not mistaken). The implication there is that
developers are using an API that looks and feels like POSIX (with some
enhancements), but can behave in "surprising" ways at times.
There are also a number of areas where the current backends could
provide more information or functionality, but because they are
constrained to a common, POSIX-like, interface, they can't.
(I'm thinking specifically of HTTP here, where the Content-Type can
contain the originating character set, which, when converting to UTF-8
is Very Useful Information ;-P)
--
Shahms E. King <shahms shahms com>
Multnomah ESD
Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B
Attachment:
signature.asc
Description: This is a digitally signed message part