[RFC] dbus-python API (re)definition

[Jeroen T. Vermeulen]

On Wed, September 6, 2006 01:11, Havoc Pennington wrote:

> For "endpoint" I've just been saying "connection" or "application"
> ("application" is slightly incorrect, but usually close enough, nobody
> really opens multiple)
>
> I think "connection endpoint" if you need to refer to only one end of
> the connection, but "endpoint" by itself I find confusing. It isn't
> present in the API at all for example.

I agree--one endpoint of a communication is always a connection, but seen
from that side, the other endpoint is not a connection but an object.  The
object in turn lives on a connection, but that connection is a waypoint on
the way to or from the object, not an endpoint in itself.

So before we can safely talk about endpoints, I think we need to agree on
the applicable level of abstraction.  From a pure messaging point of view,
you could say that all you have is interacting connections.  But that's
the "view from below" that may be more relevant to D-Bus developers.  The
"view from above," i.e. what programmers see when using D-Bus, has an
object on one end of any interaction.

In the "view from above" I don't even like to think of the connection as
the other endpoint, because somehow it feels like mixing abstraction
levels.  I'd want something that made sense in the context of the client. 
That's where I find myself groping for terms like "application" or
"service" (or indeed, "client") because unlike at the object end, there
doesn't seem to be any single abstraction for what communicates with
objects.  You call functions or your functions get called.  Very
practical, definitely, but a kind of missing page in the "object system"
story.


Jeroen