I'm inclined to reject this, or at least the part where existing Interfaces properties are deprecated:

* If you don't know what an object is, why are you using it? :-P
* If you do know what it is, you can do a single GetAll() call to get both Interfaces and (e.g.) a connection's Status, or all of an Account's properties, or most of a Channel's properties - round-trip reduction.

Thoughts from anyone else?

Your GetAll() case is compelling.

My specific case came from my work with the JS bindings, it would be nice to be able to request the Interfaces property and find out what interfaces you need to bind to the object without having to look up the object path, interpret it and then make a specific request.

Spec cabal thoughts:

This would only be useful in the presence of a GetAllForManyInterfaces() method, which is a job for D-Bus upstream.

This is also basically a workaround for deficiencies in Introspect(), which is *also* a job for D-Bus upstream. The deficiencies we care about are:

* It's a blob of XML which needs parsing, whereas if it was a normal D-Bus data structure, we'd already know how to parse it

* Bindings (dbus-glib, dbus-python) assume that every class has static Introspect() output, whereas we want to be able to (e.g.) drop the Avatars interface from Haze connections that are to an IRC server (and in extreme cases, we might not even know what we can do until we connect to the server, e.g. the OLPC "Gadget" server extension in Gabble).

The way to solve this would be to do some D-Bus upstream work in our copious free time, so, NOTOURBUG.