Adium's Broadcasting of Buddy Icons to Bonjour/AIM

[andrewjnyc]

There have been a few postings to Trac about Adium problems with buddy icons and AIM/iChat/Bonjour, but nobody seems to have posted about something I noticed that might offer a solution: If I fire up Adium in my office full of iChat users, no-one I communicate with via Bonjour can see my buddy icon....however, this is only the case with users who already have iChat running. If someone quits iChat and restarts it, the icon shows up. What this means, I guess, is that iChat "broadcasts" buddy icons in a manner that can be received by already-running instances of iChat. Adium, however, apparently doesn't "broadcast" icons in such a manner. I don't know if this is the case with AIM as well, but that sure seems to be the case with Bonjour. If there's any way this can be investigated and resolved, it'd make Adium a lot more fun to use around my office, since it's a drag that nobody else can see my buddy icon. For what it's worth, everyone's using Panther and somewhat older versions of iChat in my office--only a tiny percentage of the machines there run Tiger and its updated iChat client.

[bgannin]

As previously noted, this is a libgaim level change, not specifically at the Adium level [unless there is a provable regression between gaim and Adium]

[evands]

Not true, actually, Brian... Bonjour is powered by a separate library, libezv.

andrewjnyc: If you change your Bonjour icon while connected do people who already had iChat running (and so didn't receive your icon initially) receive the new one?

[bgannin]

Not true, actually, Brian... Bonjour is powered by a separate library, libezv.

Ah, touché. There's at least one fool here, and he's typing right now

That said, it brings a question in that is [partially] relevant... IIRC the Google Summer of Code brought Bonjour support into gaim for 2.0 alongside the file transfer improvements and others, so will we stick with another external (albeit proven) library, libezv, or will/could we move to the libgaim-provided one to reduce library overhead/complexities?

[evands]

Not true, actually, Brian... Bonjour is powered by a separate library, libezv.

Ah, touché. There's at least one fool here, and he's typing right now

That said, it brings a question in that is [partially] relevant... IIRC the Google Summer of Code brought Bonjour support into gaim for 2.0 alongside the file transfer improvements and others, so will we stick with another external (albeit proven) library, libezv, or will/could we move to the libgaim-provided one to reduce library overhead/complexities?

I haven't tried the libgaim one, but I don't know if it's mature enough for use... and there's also the question of the mDNS responder -- libezv uses OS X's, whereas I don't know what the gaim prpl expects.

It certainly doesn't offer any new features (file transfer for example) we don't have at present, so there's no pressing reason to switch I don't believe.

[andrewjnyc]

Not true, actually, Brian... Bonjour is powered by a separate library, libezv.

andrewjnyc: If you change your Bonjour icon while connected do people who already had iChat running (and so didn't receive your icon initially) receive the new one?

I won't be able to test this until I return to work on Jan 3, but I'll attempt to do so then.

Since I'm a complete naif when it comes to code-related stuff, what does it mean if it's a libezv (or libgaim)-related issue? Does that mean it's something the Adium code can't be modified to accomodate in future versions because the library code is not open-source (making it impossible to determine exactly what the library is doing)?

[bgannin]

All our libraries are open-source to my knowledge. It simply means it is occurring at a lower level and not actually in Adium code. Additionally the libraries are written as multi-platform [at least gaim is] so they are written in a much different fashion that Adium's [or to be more specific, in straight C and focused on portability instead of Objective-C]

[andrewjnyc]

All our libraries are open-source to my knowledge. It simply means it is occurring at a lower level and not actually in Adium code. Additionally the libraries are written as multi-platform [at least gaim is] so they are written in a much different fashion that Adium's [or to be more specific, in straight C and focused on portability instead of Objective-C]

Oh, OK--I thought the libraries were maybe part of OS X and therefore not open-source. If they're part of Adium, I suppose it's something you might deal with in the future, if not immediately...right?

[bgannin]

Oh, OK--I thought the libraries were maybe part of OS X and therefore not open-source. If they're part of Adium, I suppose it's something you might deal with in the future, if not immediately...right?

Well, to be exact, they are built into (i.e., used in) Adium X but aren't built by the Adium team. libgaim is built by the developers of gaim and I don't know offhand who maintains libezv but I'd assume it's another 3rd party (as is the case for libgaim.) As to whether it will be addressed - depends on whether or not anyone in Adium knows of how to fix it and has the time/drive to do so [or if it's a matter of taking updates to the library/ies and applying them to those building into Adium, which is dramatically simpler typically]

[evands]

I don't know offhand who maintains libezv but I'd assume it's another 3rd party

The library is by Andrew Wellington (proton) -- until recently the Proteus lead dev after Justin left that project. It's not really maintained by anyone, though, as he doesn't have time to code these days from what I've heard.