[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