Ubuntu moving towards Wayland

[Lennart Poettering]

On Tue, 09.11.10 23:14, Miloslav Trmač (mitr at volny.cz) wrote:

> Lennart Poettering píše v Út 09. 11. 2010 v 23:07 +0100: 
> > I think you aren't even aware how broken this "mix and match" network
> > approach of classic X11 is. The semantics of D-Bus and other IPCs in a
> > distributed X11 session has never been clearly defined, and all kinds of
> > integration between apps mostly just vanishes if you do this, or will
> > behave weirdly.
> Well, isn't that mostly the fault of D-Bus, GConf and other relatively
> recent inventions that they decided to ignore this use case of running
> desktop applications?  In the far past, IPC mechanisms somehow managed
> to cooperate with X (e.g. ICCCM, XSettings) - admittedly with
> lower-level functionality.
> 
> (The decision to ignore remote applications may have been correct -
> that's beside the point: You really can't blame X for things D-Bus/GConf
> didn't do; and the fundamental semantic problem of "should this setting
> refer to the machine this process runs or to the machine it is
> displayed" does not ever go away simply by changing the remote
> communication protocol.)

Oh, of course you can blame X for that. There's simply no sane way how
to get a "parallel" connection for D-Bus/GConf/ICE/PA/whatever to the
main X11 display connection. Something like that has been tried a number
of times, but in some way or the other it just failed in the end. It's a
can of worms. Really, for example in the GConf case I know that Havoc
spent quite some time to design the IPC so that it could be used
alongside X11 on the network, but eventually gave up on it. 

I think it is fundamentally wrong to ask us to support setups where you
might or might not share $HOME, might or might not share the D-Bus
session bus, might or might not share the D-Bus system bus, might or
might not share PA, might or might not share GConf, might or might not
share X11 displays, in all combinations over the network at all times.

Complete flexibility like that is not only impossible to manage or test,
but also inherently slow. For example: if you say the D-Bus bus should
be shared across the network, but $HOME shouldn't, then applications
could not refer to files anymore in the bus protocols, which would
basically require them to pipe everything through a bus, which is a
textbook example how to make things slow. Of course, it's easy to assume
that all the building blocks we build our desktop off would be
completely independent black boxes, but turns they aren't, and are
deeply integrated these days.

The pixel-scraping approach is the only thing that in the end makes
sense, since you have a very clear idea of what you share, and what you
don't share, and what you share is only at the very very end of what you
do, i.e. the last step of presentation of the app to the user.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.