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

Reply via email to