[Gaim-patches] [ gaim-Patches-1222377 ] [OSCAR] Improve buddy icon retrieval

[SourceForge.net <no...@so...>]

Patches item #1222377, was opened at 2005-06-17 00:39
Message generated for change (Comment added) made by evands
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222377&group_id=235

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Evan Schoenberg (evands)
Assigned to: Mark Doliner (thekingant)
Summary: [OSCAR] Improve buddy icon retrieval

Initial Comment:
When retrieving the userinfo and then using that data to request a 
buddy icon, a value in Gaim was previously hardcoded to 0x01.  It's 
called "number" in locate.c... seems that it is unclear what exactly it 
means.  In any vase, buddy icon checksums had to have a 
"number" of 0x01.  However, 0x00 is also a valid "number."  Fire 
calls this field iconcsumtype, so I've used that name for it.

iconcsumtype is passed back to aim_bart_request() where it is used 
[it will be either 0x00 or 0x01, whereas Gaim was always assuming it 
was 0x01].

The result:
Certain buddy icons which Gaim previously could not retrieve are 
now retrieveable.  I believe that these are primarily coming from old 
clients; a clear example (and my test case for finding this fix) is the 
AOLYellowPages buddy, run by the AIM server.  Before the patch, 
no icon; with the patch, the icon as properly retrieved by the official 
client.

This patch is ported... sideported?... from Fire's modified libfaim; I 
noticed Fire was doing a better job retrieving buddy icons than Gaim 
was, and hunted down the cause.

Applies against oldstatus and HEAD.

----------------------------------------------------------------------

>Comment By: Evan Schoenberg (evands)
Date: 2005-06-22 17:51

Message:
Logged In: YES 
user_id=669684

The problem was that we were being overzealous with getting icons, in a 
sense... some AIM clients send a blank GIF if no icon is set, presumably 
because this used to be necessary, using that 0x00 iconcsumtype.  The 
attached patch now avoids treating these as actual buddy icons; the 
commonality is that they have a iconlen of 90, which is not something that 
any real buddy icon would be likely to have, so we just ignore them.

----------------------------------------------------------------------

Comment By: Evan Schoenberg (evands)
Date: 2005-06-20 12:21

Message:
Logged In: YES 
user_id=669684

Clarification: I meant certain other icons, not all other icons.

Expansion: This patch also lets Gaim retrieve icons from users of recent 
versions of AOL for Windows, which was not possible before.

----------------------------------------------------------------------

Comment By: Evan Schoenberg (evands)
Date: 2005-06-19 13:13

Message:
Logged In: YES 
user_id=669684

Hmm... further testing shows that this seems to cause OTHER icons not 
to appear properly; Gaim gets an icon, but it is blank.  I'll investigate this 
further... any suggestions as to the cause would be much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1222377&group_id=235