Hi Marcel, > since InterfacesAdded is per object path, the extra Characteristics array makes sense. However that really only applies to application passively monitoring the bus objects and properties. The initiator of service discovery should only return from that method call when all other object signals have been send out. Similar to what we are doing with pairing or other potential long run asynchronous method calls. > That makes sense. Then again we don't really have a clear method for this yet other than org.bluez.Device1.Connect. We are going to have to figure out the behavior of that method when plugins and the GATT DBus API are involved as we build the new stack. I also have in mind a separate, application-specific method for creating a GATT connection (something like ConnectGatt), where the system UI would call the old Connect/Disconnect methods but applications would have to use a ConnectGatt/DisconnectGatt API that keeps track of the different dbus connections/sessions, but that's a subject for another discussion and I haven't fully thought this through yet. Coming back to your point, yes, the application that called Connect should receive InterfacesAdded for all objects before the call returns, as you said. Other applications might be passively observing these events, so they can also wait for PropertiesChanged on "Characteristics" to know that object creation for a particular service is complete. Cheers, Arman -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
