Various mostly bonjour related fixes

[Linus Lüssing]

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