Draft "StatusNotifierIcon" broken by design

Oswald Buddenhagen ossi at kde.org
Wed May 19 16:27:25 PDT 2010


On Wed, May 19, 2010 at 11:20:36PM +0200, Wolfgang Draxinger wrote:
> Am Wed, 19 May 2010 22:35:58 +0200 schrieb Marco Martin <notmart at gmail.com>:
> > the crrect way would be dbus to support other transports, there was
> > work being done on that, but i don't kno if it had any progress
> > lately (that's why images are transported in network byte order in
> > the spec, to be ready for such a case)
> 
> Well, I agree partially. DBus relies on dbus-daemon to setup the IPC
> endpoits and do all the message passing work. X11 however already
> provides certain IPC mechanisms.

> And then there's the question where the dbus-daemon should run, most
> oftenly it will run on the system where the session was started
> initially.
>
on the machine the x server runs on, managed by the display manager (or
xinit, for those stuck in the past).

> OTOH it would make sense to have such a daemon running on every system
> participating in the session: DBus was designed as low latency,
> avoid-round-trips system, but if a single dbus-daemon is running on a
> remote machine then this is broken.
> 
that's irrelevant for the display-bound bus. it's a different thing for
the session-bound bus(ses).

> I think a DBus-like IPC over X11 should be independent of DBus in the
> first place, but it should also allow for DBus message passing. And
> since X already provides all the IPC mechanisms, it would be good, if
> one doesn't have to start such an additional daemon, if no DBus is
> required, but XBus sufficient.
> 
i see no point in that. why would you want another mechanism which can
run independently? nobody's going to use it anyway. the whole advantage
would be the ability to use d-bus libs and tools, so the choice of the
right bus would be a single switch in the initialization code. possibly
with a command line option to override the default choice for cases
where the scope is not as clear-cut (examples have been discussed on
this list in the past, though nothing concrete came out of it - as
indicated in the other mails).



More information about the xdg mailing list