[RFC] dbus-python API (re)definition

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Sep 5 10:51:46 PDT 2006


On Fri, 01 Sep 2006 at 15:20:16 -0400, Havoc Pennington wrote:
> John (J5) Palmieri wrote:
> >Perhaps we should sit down and come up with a standard set
> >of vocabulary and produce a glossary.
> 
> Do you want to do this separately for python and dbus proper?

I think defining a standard terminology would be very useful, but
defining terms only within dbus-python, in a way that conflicts with their
use in D-Bus, is a bad idea. Havoc, would you mind commenting on the
glossary in <20060901113025.GA2845 at celebrin.pseudorandom.co.uk>,
sent Fri 1 Sep 2006 12:30:25 +0100?

(And indeed: would you mind commenting on whether objects changing their
supported interfaces during their lifetime is a supported operation, or
whether a given object-path on a given unique name should always keep
the same interfaces?)

> "service" on the other hand definitely is confusing, because people use 
> it ambiguously to mean a well-known bus name, a process that can be 
> launched by well-known bus name, or just "anything connected to the 
> bus," etc. So that's why we switched to the "bus name" thing.

This would be "well-known bus name", (no term defined) or "endpoint",
respectively, in my glossary. I think we could do with terms for all
three, really - it's a pity "service" has become ambiguous, since it
fits the second case best, if only via .service files
("activated service" perhaps?).

The other usage I've seen seems to be "anything which exports objects" (in
dbus-python you export D-Bus objects using dbus.service.Object,
dbus.service.signal and dbus.service.method, for instance) although I
realise D-Bus applications that don't export any objects of their own, like
nm-applet, are just a trivial case of this.

> In the end terminology isn't going to de-confuse things - a single word 
> can't explain something.

No, but it's useful to have everyone using the same word and meaning the
same thing, and it's useful to pin down relationships like "every
endpoint has one unique name, every endpoint has zero or more well-known
names".

	Simon


More information about the dbus mailing list