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.
> 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. :)