[Portland] PortlandVFSProposal

[nf2]

Hi!

Here are some thoughts on the "PortlandVFSProposal". I'm writing this 
because it would be interesting to discuss whether the "adapter 
approach" or the "infrastructure approach" is better to achieve 
consistent network transparency for all applications.

Adequate layering and *real* infrastructure:

I think the main problem of the free desktop is still that the "common 
infrastructure layer" for desktops and applications is too thin. If the 
layering would have been done correctly there wouldn't be a necessity 
for project portland, RuDI,...

* Desktop/Application Layer (Presentation Layer)
* Common infrastructure layer (xlib, main loop, network transparency, 
keyring/wallet, printing,...)
* Kernel

My prediction is: If the Gnome and KDE communities don't have the 
courage get the layering right (by dumping things they have implemented 
in the desktop layer, but shouldn't be there) the free desktop(s) are 
going to fail or one of them has to win. Fixing the layering dosen't 
mean that the public API's have to change, but the backends.

One example of problematic layering is revealed when moving from KDE3 to 
KDE4. Because KDE's network transparency is sitting in the desktop 
layer, Qt3/KDE3 applications can not use the same VFS infrastructure as 
KDE4 apps. Using some GNOME applications as well, it might happen that 
there are three!!! network transparency systems on the same desktop, 
which all behave differently.


Options to share network transparency to all applications running on a 
desktop:

1) "infrastructure approach": A Common-VFS.  Filedialogs might be 
specified to look similar or have switchable layout-modes (XSETTINGS?)
2) "adapter approach" Adapter to KIO/Gnome-VFS and filedialogs (the 
RuDI/desktop adapter approach).


Common VFS:

Personally i think the best solution to get network transparency right 
is still the Common-VFS. Clearly network transparency belongs to the 
infrastructure layer and not the desktop layer. With a Common-VFS you 
earn consistency for all applications instantly. You don't have to 
rewrite applications (like Evolution) to act in a cross-desktop way.

In contrast to D-VFS the Common-VFS is not specified by the API but by 
the necessity to serve both the KIO::Jobs API and the Gnome-VFS API at 
the same time. Therefore it needs an async and a synchronous interface 
(a superset of both systems).

I think the design should be hybrid - a conceptual mixture beween 
KIO-slaves and Gnome-VFS:

1) Backends can run in the process of the application (using threads for 
async behaviour) (Gnome-VFS mode)
2) One slave process per client connection (traditional KIO mode)
3) One slave process per protocol
4) One slave process per remote user at server

Language: C (perhaps with a dependency to glib)
IPC: DBus for signaling and homegrown like the kio-slaves protocol for 
the data connection.

I think the easist way to start, would be to port KIO SlaveBase and 
SlaveInterface to C and D-Bus and remove the Qt-dependency. Because the 
Object-Oriented level of KIO slaves is not very high (i guess), porting 
them to C should be easy.

older stuff:
http://www.scheinwelt.at/~norbertf/common-vfs/
http://www.scheinwelt.at/~norbertf/common-vfs/newdesign.html


The Common Main Loop

I think the "common main loop" should also be on the Portland "menu", 
because writing the client part for every infrastructure library twice 
would be insane.

regards,

Norbert