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

[nf2]

Hi,

Lubos Lunak wrote:

>On Wednesday 07 December 2005 13:00, nf2 wrote:
>  
>
>
>>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.
>  
>
But this won't differ from running ordinary KDE applications. With my 
desktop adapter prototype i didn't recognize any extraordinary delay 
when opening KDE file dialogs.

What i meant with performance/memory cost of an out-of-process approach is:

* requiring daemon process(es). perhaps multithreaded or one per 
application. (designing and dealing with them will be quite a challange)
* marshalling + buffers
* context switching

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

Wrapping a high-level IPC protocol around something like the KIO-Jobs 
API will be extremely tricky. I reckon you can't just use DBUS messages 
as usual. Plus file-data has to cross another IPC bridge (more context 
switching!).

>
> 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.
>  
>
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.

> 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.
>  
>
Hmm - i guess KApplication shouldn't be a subclass of QApplication...

Do you think this could be solved by creating a KApplication instead of 
a QApplication for a Qt program? For instance the desktop adapter could 
provide an init_backend() function, which should be called before 
creating the QApplication:

I->init_backend(...);  // creates a KApplication if the desktop adapter 
runs on KDE.
if (!qApp) new QApplication(...);

I'll try to analyse that particular problem with my prototype. AFAIK 
Gnome and Gtk+ are easier to deal with here.

> 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.
>  
>
Is it only global variables like qApp or are there other troublemakers too?

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

> 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.
>
>  
>
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.

Cheers,
Norbert