Hi Glenn, Thanks for your feedback. The github.com/lathiat/avahi repository is actually “official", and not a fork as such.
Your analysis is correct, per the ticket this issue was recently raised by someone else for use with Python as well. It’s a deficiency in the current D-BUS API. This works fine for us in libavahi-client because we subscribe to all signals from Avahi up front, before any objects are created. This however, does not work for dynamic usage of the D-BUS API with Introspection, such as used with Python. They create the object, and can only then subscribe to it (because it did not exist before). This almost seems like a deficiency in the D-BUS APIs but I guess we have to work with it :-) I plan to fix this by adding to the D-BUS API, I am told that the “common” fix for this is to add a catch-up command that requests that all messages are re-sent. My main concern with this is that it seems like a race condition in it’s own right, we may send duplicates and with bad timing the client may also get removals for additions they had not yet seen. So I needed to put some more thought into that. The other fix would be to have a “Start” signal to call after subscribing to the events, however that would break existing applications. But they may well be the best fix, combined with putting that requirement under a new version of the API and to offer both simultaneously. I would love your feedback on if you have any thoughts and what would best work for your Go binding. I would also love to integrate the go binding into the official tree and releases — please let me know if we can work together on that :-) Cheers, Trent > On 2 Sep 2015, at 3:27 AM, Glenn Martin <lifewar...@yahoo.com> wrote: > > It seems the entire problem above is related to a Signal API race, i found > some information about on a GitHub fork of the project: > https://github.com/lathiat/avahi/issues/9 > <https://github.com/lathiat/avahi/issues/9> which i think is mirrored in this > ticket as well on the formal Avahi website's tracker: > http://www.avahi.org/ticket/247 <http://www.avahi.org/ticket/247> > > The solution was fairly simple, I simply pre-register for all notifications > for a browse object without knowing the path before calling in to existence > the Browser object. I can then buffer the results and filter out any that > didnt come from my specific instance. This feels a bit messy but it is > effective for me at the moment. > > I hope this information helps others. > > Glenn Martin > _______________________________________________ > avahi mailing list > avahi@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/avahi
_______________________________________________ avahi mailing list avahi@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/avahi