[RFC] dbus-python API (re)definition

[Havoc Pennington]

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.

Havoc