"default" object path
David Zeuthen
david at fubar.dk
Fri Oct 16 15:42:32 PDT 2009
On Fri, 2009-10-16 at 23:57 +0200, Thiago Macieira wrote:
> Em Sexta-feira 16. Outubro 2009, às 23.27.52, você escreveu:
> > On Fri, 2009-10-16 at 23:18 +0200, Thiago Macieira wrote:
> > > Make / the default object. Easy to type, even on busybox on an embedded
> > > device.
> >
> > No, that's really bad advice, the object path name space is essentially
> > system-wide. See this blog entry (and comments) for specific details on
> > why this won't work in general:
> >
> > http://0pointer.de/blog/projects/versioning-dbus.html
>
> There are no arguments against placing many interfaces in the same object in
> that link.
Several times actually. Let me repeat it the argument then.
Consider two services with names org.Foo and org.Bar both exporting the
"manager" object at /. Suppose both services supports an hypothetical
shared and well-known interface called org.freedesktop.Service. Suppose
this interface has a signal ServiceIsIdle() that lets users know the
service is now idle.
Initially we have two different processes (e.g. different unique bus
names) owning org.Foo and org.Bar. There is no problem, apps can
reliably receive the signal ServiceIsIdle() and life is good.
Suppose now that we have a single unique bus name, say :1.42, owning
both org.Foo and org.Bar. This is perfectly valid and I bet we will see
this happening more in the future as distros consolidate all the system
services. Anyway, now org.Foo emits the ServiceIsIdle() signal. This is
sent to the message bus. The bus rewrites the org.Foo name present in
the header to :1.42.
What happens now?
Well, clients just receive a message saying that the object / owned
by :1.42 emitted the ServiceIsIdle() signal on the org.fd.Service
interface. What clients _don't know_ is that whether it was org.Foo or
org.Bar that emitted the signal. They just can't know.
Hence, putting objects at '/' is a horrible idea.
If you read the archives of this list you will see that people have been
saying this over and over again. Most of the time on the "trust us,
don't do it" level. I hope this is a good technical explanation though.
Thanks,
David
More information about the dbus
mailing list