On Sep 26, 2006, at 12:47 PM, Mark Doliner wrote:

Hmm, is this the code for uploading your own icon?  It seems like you would

only want to have one of those at a time?  If someone sets their icon twice in

quick succession, you could just cancel the first one.


If I'm wrong, then yes a GSList of GaimProxyConnectData structs is a good

idea.  Or maybe even a hash table, but that seems like overkill.


Looking at the code a second time, I see that I was mixing up the yahoo_send_picture_*() and yahoo_buddy_icon_upload_*() functions.  The former can have several in progress at once, appear to send directly via the yahoo connection, and don't do a gaim_proxy_connect().  The latter do a gaim_proxy_connect() and are for uploading one's own buddy icon to the server -- so you're  right, you would only want one at a time.

In any case, having the proxy code pass back GaimProxyConnectData as a

parameter is probably a good idea.

Agreed.


When I did the cancelable stuff I thought about being able to pass in a

handle/reference thingy like the notify and request APIs, and then you could

call something like gaim_proxy_request_close_with_handle(gc), but that seemed

a bit over engineered to me.  I figured I could always do it this way and if

it started to get messy then I could change it.  I guess I would suggest first

changing Yahoo! to keep track of the GaimProxyConnectData(s), and if the code

is really ugly or people want to use the handle paradigm then we can change it.

Without having to add and remove from a list, the fix should be quite clean here, as it has been elsewhere previously.  It wouldn't be bad for all this to be handled by the core automatically rather than for each prpl to have to deal with it... but I wouldn't remove the current implementation because it's very nice to be able to cancel selectively at will -- as we see in this case, where a second buddy icon set should cancel a first if it is in-progress.  The current implementation is Good and seems to be sufficient. :)

-Evan