[Portland] Project Portland, RuDI and the Generic desktop adapter

[Martin Konold]

Am Donnerstag, 8. Dezember 2005 22:34 schrieb nf2:

Hi,

I think the discussion boils down to wether solve the problem in-process or 
out-of-process.

Funny enough I came to the conclusion that correctly done out-of-process 
solves some issues nicely. These are namely

- version skew. out-of-process has less problems with ABI stability and allows 
for backward and forward compatibility

- licensing concerns. ISVs are very much into not having to deal with too many 
licenses.

- memory consumption. If done correctly o-o-p uses less memory than i-p. This 
is mainly due to the fact that reusing an already existing process is much 
more memory efficient than trying to save memory with copy-on-write semantic 
of shared libraries

- cpu usage. Due to the fact that less initialization happens o-o-p can be 
more efficient than i-p if done correctly. Funny enough context switching is 
not such a big issue anymore since kernel 2.6. In contrast to this the 
dynamic linker is still incredibly slow and does not scale with the number of 
symbols.

- support for many developement environments. E.g. the i-p approach does not 
easily solve how to integrate JAVA or Ruby applications with the desktop. 
Especially ISVs use all kind of toolkits, languages and tools we can not 
limit ourself to only support gtk and qt.

> I know that KIO-slaves use a socket protocol. But it's lean and fast,
> because it has been designed for one particular purpose.

I currently don't intend to transfer large junks of user data over any RUDI 
IPC mechanism. Instead it shall only transfer references.

> Coexistence problems are very interesting and should be analyzed and
> sorted out anyway (for things like GParts/cross desktop components). But
> i agree with you that this is the difficult part of an in-process approach.

The goal with RUDI is much lower. It is not about sharing actual code and 
implementation but more about makeing things interoperable and integrative.

> Hmm... But on the other hand out-of-process would give them a 3rd class
> ticket for the desktop ride. ;-)

Not really, I think it is mandatory that the provided technology is 1st class. 
Actually I think it makes most sense to use it in most cases. E.g. for all 
the ISVs offering KDE applications on kde-apps.org I thnik that using o-o-p 
is the right thing to do. This will allow them to run on any version of KDE 
without BIC problems.

> I agree. It always depends what you wanna do. File-dialogs would be
> possible out-of-process. High performance stuff like VFS will be harder.

Why should we cover VFS fromt the applications point of view. Why can't the 
functionality of VFS be handled by the desktop and simply be used by the 
application.

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker