Hi Luiz, thanks for your outstanding response times for all these GATT issues popping up on the list. > from: Luiz Augusto von Dentz [mailto:luiz.dentz@xxxxxxxxx] > <Markus.Kasper@xxxxxxxxxxx> wrote: > > but instead (for whatever reason) > > in some other order. In my case I get the order ... > > I bet this is because of the use of hash table by your binding, this would be > fine if the objects don't have a relationship between themselves. An internal hash table as root cause would make sense to me. > > 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. > > I actually had to fix this with use of OrderedDict to make sure the order of > objects is maintained so we can parse in a single pass the objects. I somehow expected something like this when I noticed the OrderedDict =). > > 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. > > It is a bit ridiculous since it is probably easier to implement with a list and > maintain the order as seen in InterfaceAdded, but I have to agree that we > can't rely on the peer to make this easier for us. Well, this wouldn't be a problem at all if this wouldn't imply that users have to adapt their DBUS libs for interoperability. The lazy fix would be clarifying the API doc and leaving the work to the peer. > Yep, we will have to store the proxies and later process them on ready, so it > becomes a little more complex. As a workaround (or later patch) I'd currently go for 1. Adapt proxy_added_cb to fill a list or queue 2. Adapt app struct to provide this list or queue data structure 3. write a new function for iterating three times* over this list to create 1) services 2) characteristics 3) descriptors using the former code of proxy_added_cb 4. call this function from within client_ready_cb *Alternatively one could add 3 categorized lists and iterate only once. Somehow I fell both solutions are a bit ugly, but will work. Does this make sense to you, or do you have a more Elegant approach/some addition/hint why this might turn out to fail? > Most IPC are asynchronous, actually the fact that you notice it and learn is > probably much more valuable than it simple magically working since the later > would mean the IPC library is creating a thread behind your back which can > cause a lot more problems for you. You definitely have a point here. > D-Bus has integers but not enums as the document seems to suggest, C > enums are integers but you can associate with a symbol at least, besides it is > a lot easier to understand a string than integers with things like d-feet and > dbus-monitor. This is a totally valid argument towards using strings during design/debug. Nevertheless with respect to performance (thinking about embedded applications) string parsing this might make a difference. Obviously the GATT API isn't a prime example when arguing about performance as it is not called very frequently and thus shouldn't make any difference. Thanks for your help. Markus > -- > Luiz Augusto von Dentz ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
