Various mostly bonjour related fixes

[Eion Robb]

Oops, 2.10.1 didn't compile on win32 with the new linklocal detection code.
 Patchs at http://developer.pidgin.im/ticket/14802 fixes the issue.

On 9 December 2011 01:26, Linus Lüssing <linus.luessing at web.de> wrote:

> Hi Mark, hi Ethan, hi Kevin,
>
> Thanks for having a glance at these patches.
>
> On Tue, Nov 29, 2011 at 11:24:20PM -0500, Ethan Blanton wrote:
> > Mark Doliner spake unto us the following wisdom:
> > > On Tue, Nov 29, 2011 at 7:21 PM, Ethan Blanton <elb at pidgin.im> wrote:
> > > > Mark Doliner spake unto us the following wisdom:
> > > >> I guess I'd prefer if we didn't commit these to 2.x.y.  Supporting
> > > >> ipv6 for bonjour doesn't seem critical to me.
> > > >
> > > > Please clarify what you mean by "these".
> > >
> > > I guess I meant all of them.  And I don't have a strong opinion about
> > > this.  I guess I'm mostly saying that _I_ wouldn't have committed them
> > > to 2.x.y.  It's probably not worth reverting the changes from 2.x.y.
> > > And I'm not going to stop anyone from committing the remaining patches
> > > to 2.x.y.  But we should be EXTREMELY careful not to cause other bugs.
> >
> > I generally agree; however, I can confirm that Bonjour + IPv6 = not
> > good at the moment, and the patches which have already been applied
> > should not affect anything but Bonjour (they are all local to the
> > Bonjour plugin) on IPv6 (they come into play only for IPv6 addresses).
> > The way I see it, we're unlikely to break anything that isn't already
> > broken.
>
> Yes, those ones are all supposed to be just fixes and should
> address critical issues with bonjour if IPv6 is activated in
> avahi.
>
> >
> > The remaining patch is a bit of a different story.
>
> Oki doki. As it's only related to the file transfering in bonjour,
> I guess I can live without it in a 2.10.1 release as long as it
> doesn't take too long for a following release.
>
> However I'm currently wondering whether other protocols might have
> issues with purple_network_do_listen() / purple_network_listen()
> on some operating issues. At first I thought having read somewhere
> that the order of addresses returned by getaddrinfo() was
> unspecified. Now I searched again and it looks like RFC3484 is
> responsible for the ordering. I couldn't quite figure this out yet
> - does it ensure that ::ffff:0.0.0.0 (mapped IPv4 wildcard) is
> always prefered over ::0 (IPv6 wildcard)?
>
> If not, wouldn't it be better to change AF_UNSPEC to AF_INET in
> purple_network_listen() until purple_network_do_listen() is doing
> what it is supposed to do?
>
> > Patch 2 (fix socket listen address) requires a minor version
> > bump, as it adds API.
>
> Just for clarification (I'm not really familiar with the
> development/release process in pidgin): My impression was
> that in the 2.10.0 API purple_network_listen() was supposed to
> offer both IPv4 and IPv6 connectivity in case of AF_UNSPEC (which
> currently is not the case). Is any change that tries to allow this
> supposed behaviour considered an API change needing a minor
> version bump? When do you consider a behaviour change
> in the API being a fix instead?
>
>
> On another note, I would like to remove this Windows XP disclaimer
> in the second patch. It'd probably be the best to create two
> separate sockets for IPv4 and IPv6, right? Which as far as I know
> would require a far more invasive patch instead - or does anyone
> with some better knowledge of the libpurple API have an idea about
> how to achieve this easily?
>
> >
> > Ethan
>
> Cheers, Linus
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20111213/f486873d/attachment-0002.html>