[RFC] dbus-python API (re)definition
hp at redhat.com
Tue Sep 5 16:51:43 PDT 2006
Matthew Johnson wrote:
> As a side point, I don't think just saying 'there's no technical reason
> in libdbus that it couldn't be done' is good enough. D-Bus is
> object-oriented, whereas libdbus is message oriented. There are
> definitely some things which you can technically do with libdbus which
> we definitely want to say are not supported in D-Bus. For example
> replying to methods with a different type or number of return values
> each time is definitely not supported in D-Bus, but you can technically
> do it with libdbus (-:
Agreed, as always the question "is XYZ supported" is a bit vague.
If someone asks "is changing your interfaces supported?" then if they
are trying to figure out how to write a really paranoid app that will
handle whatever the remote app does, the answer is yes it's supported by
the protocol, they have to handle it.
If they are trying to figure out if their normal app should bother doing
something sane if the remote app does this unexpectedly, the answer is
no. There isn't some intentional feature related to interface changing,
it's just that the protocol has no way to (efficiently) prevent or
enforce it (and in fact the protocol is guaranteed not to try, imo).
If someone's asking, can I create a well-defined way to change my
interfaces, by e.g. having an API where objects can be "withdrawn," or
emit an InterfaceChanged signal, or whatever; then sure, go for it. I
think there's no reason this isn't allowed, though I also don't know why
you would do it offhand.
More information about the dbus