Re: [PATCH] A NSNetService implementation using Avahi

[Fred Kiefer]

I only had a short look at this patch and was a bit surprised to see how
little these two implementations share. In a normal class cluster you
would expect that most of the code is in the common super class and only
the primitive methods get implemented separately. What was the reason
for doing it differently here? Even the delegate handling methods are
duplicated, with the mDNS ones having an additional tracing call.
Apart from that your patch makes perfectly sense to me.

Fred

PS: You seem to be using tabs to indent your code. Spaces (two of them
actually) are prefered.

Am 26.03.2010 02:58, schrieb Niels Grewe:
> Hello guys,
> 
> here [0] you will find a patch (slighly to large for attachment) that
> I've been cooking up for some time now. It augements the present
> implementation of NSNetService and NSNetServiceBrowser in gnustep-base
> with a second implementation using the Avahi API. Some words on why that
> seems to be a good idea to me:
> 
> Our present implementation of NSNetServices makes use of the API that
> Apple implemented in mDNSResponder [1] to provide zeroconf (=Bonjour)
> services. That is, in principle, a good idea, because we can bet that
> Apple also used it to implement NSNetServices on Mac OS X. The problem
> is only that (way back) mDNSResponder was APSL licensed [2], which was
> hindering adoption by some Linux distributions, so it is not available
> on many Linux systems.
> Fortunately, the Avahi project provides a compatibility layer for the
> mDNSResponder API that can be used instead. Unfortunately, that
> compatibility layer is only partitially implemented and (apparently) not
> very well maintained. This means that presently our NSNetServices code
> will run on most Linux distributions where avahi is available, but most
> of the shiny stuff you would want in an useful application (e.g.
> monitoring TXT records) wont work.
> 
> Since Avahi is probably going to stick on the Linux desktop (it provides
> a DBUS interface that seems to be quite popular for reasons unknown to
> me), I decided not to waste my time on fixing the Avahi compatability
> layer, but to reimplement NSNetServices on top of the native Avahi API.
> This was actually quite easy, because avahi provides some hooks that
> allowed hooking the event-handling into NSRunLoop quite transparently.
> This has the following ramifications:
> 
> 1. NSNetService and NSNetServiceBrowser are now abstract superclasses
>    that return concrete subclasses for the configured implementation.
> 
> 2. The zeroconf API to use is now configurable by the
>    --with-zeroconf-api configure switch. It can take the values "mdns",
>    "avahi" and "any" (with "any" being the default). If both are
>    installed, it will always use avahi, since the mDNS implementation is
>    most certainly the broken compatibility-layer.
> 
> 3. The new avahi-based implementation has some shiny additional features
>    that make it more flexible then the Apple one. I.e. it allows you not
>    only to browse for (or register) services and TXT records, but also
>    arbitrary records. This is nice for use-cases like serverless
>    XMPP-messaging, where you are supposed to publish a buddy-icon as a
>    NULL record. While these features are not yet available with our
>    mDNSResponder-based implementation, they are certainly possible, and
>    I would be adding them eventually if there is sufficient interest.
> 
> I'm now soliciting feedback on this patch. It still has some
> non-critical FIXMEs strewn over it that I plan to resolve, but in
> general it seems to be quite usable. So if you have any code that uses
> NSNetService and friends, please try it out and tell me when it breaks
> and where it doesn't behave as expected. To this purpose, I have also
> uploaded the patch to the Étoilé reviewboard [3].
> 
> Thanks,
> 
> 
> Niels
> --
> [0] http://www.halbordnung.de/~thebeing/gnustep/NSNetServices+avahi.patch
> [1] http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-214/
> [2] It's Apache-licensed now.
> [3] http://review.etoileos.com/r/137/
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev