[RFC] dbus-python API (re)definition

[Havoc Pennington]

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.

Havoc