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

[Lubos Lunak]

On Wednesday 07 December 2005 13:00, nf2 wrote:
> Hi,
>
> May i join in your discussion? :-)
>
> I have already written a poposal and a prototype for a cross desktop
> interface in between applications and desktops, called "The Generic
> Desktop Adapter". It seems very close to what "RuDI" wants to achieve,
> but using a traditional in-process library approach with dlopen().

 Yes, it seems to be about the same, just with a different "transport" 
mechanism.

>
> http://www.scheinwelt.at/~norbertf/dadapt/
>
> Perhaps you can give me some feedback on my proposal and tell me if it
> makes sense to continue working in that direction.
>
> What do you think?

 Let me comment on some of the things from the page:

> RuDI - but it would require IPC plus daemons. IMHO using IPC would just be
> workaround for not fixing the mainloop thing, causing complexity and costs
> in performance/memory which seem not reasonable here.   

 Just to give you something to compare these costs to, doing a dlopen of the 
KDE library that provides the KDE file dialog takes about 0,4-0,5s on a 
900MHz machine and causes somewhere between 0,5 and 1 MiB of unshared (i.e. 
per-process) memory (I can't find out the memory usage exactly because 2.6 
kernels apparently can't give a number of dirty pages for a process). That's 
all caused just by the dynamic linker. The time issue could be fixed e.g. by 
Michael Meek's -Bdirect, the memory usage can be probably avoided only by 
non-trivial improvements in prelink.

> Just an example: Providing filedialogs means that applications also need
> access to VFS ("network transparency") libraries for downloading and
> uploading files. Streaming file-data with SOAP, D-BUS or any similar socket
> protocol is a performance nightmare.    

 Actually KDE's KIO uses IPC (plain unix domain socket) for communication 
between the kioslave and the application. I don't remember anybody 
complaining about it. Also, things like filedialogs are actually not that 
performance demanding, as far as the application<->dialog communication is 
concerned.


 As for complexity, I think it's not so clear whether IPC increases or 
actually decreases the complexity. If you use another process, you have a 
very clear separation, if you do everything in-process, you have several 
codebases that must coexist nicely.

 For example, it is not possible to dlopen KDE3 libraries from Qt3-only 
applications because of something called 'kapp pointer'. In a nutshell, every 
Qt application has exactly one so-called application object inheriting from 
QApplication, which KDE extends to KApplication, and kapp points to the 
KApplication instance - however Qt-only apps create QApplication and so it's 
not possible to create KApplication, so the kapp pointer cannot be valid. 
Because of binary compatibility reasons we can fix this only for KDE4.

 And this problem exists when trying to combine Qt and KDE (in a rather 
unusual way, indeed), two things that are otherwise very close, because KDE 
depends on Qt. Even though in this case that was probably rather the problem, 
which one shouldn't have with two totally independent toolkits, can you be 
really sure you won't have other unexpected interactions when mixing two or 
more completely different codebases? You can have them sometimes even when 
using just a single codebase.

 Moreover, now that I think of it, I wonder if some ISVs wouldn't have issues 
with loading other large libraries into their applications, for whatever 
reason.

 Of course, out-of-process approach has its disadvantages too, just different 
ones. We need to compare the approaches after we specify the problem. And we 
haven't done that very precisely yet.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/