Hi, it seems I‘m among the first users out there using the dbus API for implementing a GATT server via C & gio & gdbus-codegen. So first thanks to Luiz for the recent patch and the new great RegisterApp API, which solved some trouble with gio and the contradicting hierarchy requirements for the ObjectManager. I’m using a rather recent checkout of the git. Unfortunately I ran into another problem with dbus incompatibilities: When registering an application the gdbus/client.c parses the interfaces and adds proxies based on the results of a GetManagedObjects call. What happens for me is that the gio implementation does not return the objects in the order I added them, but instead (for whatever reason) in some other order. In my case I get the order service0/char0 service0 service0/char1 Instead of service0 service0/char0 service0/char1. When parsing/adding interfaces the order of the objects returned from the GetManagedObjects call is preserved. Thus instead of first adding the service and then adding the characteristics, the current implementation starts adding a characteristic and then fails registering the server because the corresponding service is still missing. I expect similar issues with “out of order” descriptors, but did not test it. I also didn’t test “shuffling” objects within the Python example-gatt-server, but this should most likely be the fastest way to reproduce the problem and test solutions. At the end of the day for best interoperability I suggest to avoid relying on the order of the GetManagedObjects reply in bluez, but instead aim for a robust parsing. I’m actually not sure what would be the best place and method to fix this. Patching within gdbus/client.c would be quite easy, but I think the dbus implementation shouldn’t care about application requirements. Fixing within the gatt-database.c would most likely be a bit cleaner, but requires (at least at a first glance) moving towards some approach where we first register all interfaces and ignore all errors, and then do a consistency check of the hierarchy afterwards, when all is done. Another smaller issue I stumbled upon is the requirement to call RegisterApplication asynchronously to allow for answering the calls to the object manager. While this might be a natural thing for experienced DBUS developers I feel it would help beginners to mention this within the docs (= it would have saved me some hours of debugging). Thanks for your great efforts on maintaining and extending Bluez. Btw: is there a good motivation for using strings instead of intergers/enums within the DBUS API (e.g. flags)? I recently read http://dbus.freedesktop.org/doc/dbus-api-design.html and would love to see some of the suggestions being mapped to the API before it leaves experimental status. Cheers, Markus ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
