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

[Alex Graveley]

Martin,

I don't think it boils down to in-proc/out-of-proc at all.  I consider 
this, as well as any late-binding approach to be completely 
implementation detail.  Ones which we should not even begin to decide 
upon until we know exactly the problems we are trying to solve.

-Alex

Martin Konold wrote:
> 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
>