nf2 at scheinwelt.at
Sat Jan 7 11:21:14 EET 2006
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,
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
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).
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.
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.
More information about the Portland