[RFC] dbus-python API (re)definition

Havoc Pennington hp at redhat.com
Tue Sep 5 11:11:29 PDT 2006


Simon McVittie wrote:
> 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?

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 have been using "peer to peer" for the no-bus case but people do get 
confused by it and think multi-computer P2P. Sometimes I try to say 
"direct connection between two apps" or something instead for that reason.

I don't think there's a need to introduce the "unnamed interface," 
omitting the interface from a message just means "search all interfaces"

Really this is a protocol detail most people needn't care about.

> (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?)
> 

I don't think it's really a good idea (many sane remote apps would be 
confused by it) but there's nothing in the lidbus library or protocol 
that does or could prevent it from happening. If for some reason someone 
was confident their object users would be OK with this, due to nature of 
the API, control over code using the object, or whatever, then I don't 
think there's any reason people can't do this.

In other words it's probably a dumb thing to do, and few people will 
want to do it, but it's not prohibited per se.

Havoc



More information about the dbus mailing list