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

[Lars Knoll]

On Friday 09 December 2005 03:35, nf2 wrote:
> Aaron J. Seigo wrote:
> >that said, your approach does require AFAICS unifying the event loops.
> > which cuts out any and all apps that aren't written to those toolkits
> > that adopt that event loop. this means for most apps that the authors
> > will have to port to a newer version of their toolkit before taking
> > advantage of such an approach which in turn often has a fairly
> > significant cost for them.
>
> Qt3, Gtk+ 2.0 and Xt. I would assume they could all be ported to a
> shared main loop without breaking API's.

It can be done with Qt and Gtk. I'm not so sure about Xt.

> >the IPC approach also works better with apps being run remotely on a
> > different machine than the desktop is, but that's perhaps a corner case
> > these days.
> >
> >as for ABI stability, saying that it isn't a problem because we already
> > link to .so's is like saying that complaining about the flu is silly
> > because you've had flus in the past. the idea is to avoid past problems,
> > not find creative new ways to repeat them. ISVs are highly allergic to
> > ABI stability issues, which is why many use as FEW libs as possible,
> > statically link when possible and often even ship their own versions of
> > the .so/dll when that fails.
>
> I just said that because i thought problems should be fixed at the
> lowest possible layer. Bypassing them with daemons and IPC looks a bit
> like an overkill and should only be the last choice.

I think most of us agree that unifying event loops is a good idea. It will 
however not solve every issue. One of the main problems I see with an 
in-process approach is potential stability and security issues.

ISVs test their application with a set of libraries they link against on a 
certain desktop. an in-process approach basically means that the application 
developer can not know what kind of code might get executed in it's process 
space. 

The other problem is interoperability between different major versions of the 
same library (Qt3 vs Qt4, Gtk2 vs a future Gtk3). These usually define 
similar sets of symbols which could lead to larger problems when loading them 
into the same address space.

So I think that even though an out-of-process approach looks like overkill 
it's the safer road to go. On a standard desktop environment you will 
probably also not need a special daemon as the desktop has applications 
running that can just take over these functions.

Cheers,
Lars