[Portland] PortlandVFSProposal

[Bastian, Waldo]

>>KDE's KIO has been written to handle
>>1) Slow unreliable (read: remote, read: NFS mounted) filesystems.
>>2) I/O related user interaction
>>
>>Wrt 1. By using an asynchronous out of process approach, the
application
>>is not affected by network delays and allows to remain responsive.
>>Although this could nowadays be achieved with in-process threading as
>>well, separate processes are still considered preferential in order to
>>maintain stability by separating the application from protocol
handling
>>code. E.g. the protocol handler (KIO process) can crash or be killed
>>without negative impact on the application (and without memory leaks).
>>
>>A key benefit of the KIO approach is that it allows protocol handlers
to
>>be written using synchronous code paths, making it easy to use a
variety
>>of existing protocol specific libraries.
>>
>>I think hiding from applications the fact that data resides across a
>>network, as fuse attempts to do, is a fundamental wrong approach since
>>this aspect has a major impact on the end-user experience. In
particular
>>all kinds of assumptions that application developers tend to make
about
>>disk access start to break down. KIO replaces the expectations that
>>application developers have wrt a local file system with a new set of
>>expectations applicable to KIO allowing application developers to
design
>>their application around this new set of expectations.
>>
>>There is a very nice Sun technical report that touches on this issue
in
>>a slightly different context:
>>http://www.sunlabs.com/techrep/1994/abstract-29.html
>>
>>Cheers,
>>Waldo
>>_______________________________________________
>>
>>
>The only problem about KIO is that it has not been designed as common
>infrastructure (in a toolkit and desktop independent way).
>
>Do you think it would make sense to rewrite KIO in C and to wrap a
>synchronous and async API around the slave protocol (that it can serve
>both the KIO::Jobs and the Gnome-VFS API.

It's easy to go from asynchronous to synchronous, that's what
KIO::NetAccess does.

>From an application point of view, to solve the "app doesn't know how to
open weird URL" problem, it would be sufficient to have a KIO::NetAccess
like API. I will have to take a look at Gnome-VFS to see how similar
that one is. You could make a D-bus service to offer KIO::NetAccess like
functionality which then delegates to either KIO or Gnome-VFS. That
could be a useful partial solution.

Rewriting parts of KIO in C is certainly possible, the biggest technical
hurdle is to document the current implicit assumptions in the code, in
particular what the various KIO::Jobs expect from the protocol handlers.
I believe someone has actually once written a protocol handler
(kioslave) for KIO in C already as a proof of concept.

The low level wire protocol of KIO is very much fixed (it's marshalling
is Qt centric but that's documented so it's no problem to implement that
under a different framework, or to switch to a different marshalling)
the protocol handler at the other side could be using any framework it
likes. You would want to offer framework bindings (similar to dbus
language bindings) that make it easy to write a protocol handler using
your preferred framework.

Cheers,
Waldo