[RFC] dbus-python API (re)definition
hp at redhat.com
Fri Sep 1 12:20:16 PDT 2006
John (J5) Palmieri wrote:
> proxies and service should be renamed. Proxy is a bad word to use and
> so is service. I like consumer/provider as an idiom since this is not a
> strict one to one client/server architecture. I'm not sure if those
> make good module names. export is ok, though I'm not sure if I like
> that either. 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 feel
like we've been converging on terms for dbus proper (in tutorial, spec,
and API) and have been using proxy but not service.
To me consumer/provider is just wrong; consumer/provider is normally
used for a unidirectional queue, which dbus connections are not. A dbus
conversation is "full duplex"
publish/subscribe is right for signals but not method calls.
I haven't had the sense that proxy is confusing; meaning, people may
need the term defined, but once they hear what it is they "get it"
"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.
"service" does kind of remain with .service files, but kind of makes
sense in that context I guess.
In the end terminology isn't going to de-confuse things - a single word
can't explain something. A nice clear tutorial and docs (combined with
consistency in terminology across docs and API) will be the key.
More information about the dbus