Gadu-Gadu protocol update and patch

[Elliott Sales de Andrade]

2009/8/26 tsalacinski at gmail.com <tsalacinski at gmail.com>

> Current code gives the pointer to crc32 value. Then, when
> ggp_send_image_handler function is launched, g_hash_table_lookup uses
> a different pointer - to ev->event.image_reply->crc32. That's a
> different pointer, so the image is not sent (because
> g_hash_table_lookup returns NULL, and then imgid = 0 and there's no
> data under that id).


They are obviously different pointers, but are you sure they're the same
crc32 value?


> Unfortunately g_hash_table_lookup accepts pointers as arguments, not
> values. While I have the CRC, I need to pass its value to some other
> function and get the imgid. If I am wrong, please correct me.
>

A GHashTable can take anything as a key. It's just necessary that the
hash/equal functions you use understand what you gave it. In this case, the
hash table was created with g_int_hash and g_int_equal. Thus, it uses a
pointer to an integer as the key. The fact that they are different pointers
is irrelevant because g_int_equal checks the values pointed to, not the
pointer.

All what is needed is to store crc32->imgid pair and make it available
> to ggp_send_image_handler function. When having imgid, I can retrieve
> the image's data from purple_image_store and then send it to other
> user. Current g_hash_table method doesn't work at all (it didn't send
> any image I've tried to send, g_hash_table_lookup always returned
> NULL).
>

Why store the imgid when you can store the PurpleStoredImage itself? That
would cut out one extra lookup. In fact, you could create the hash table in
such a way as the image is automatically unref'd when removed, thus limiting
any leaks (like when the connection ends and there are still images ref'd (I
see they're only unref'd when sent)).


> W dniu 27 sierpnia 2009 02:58 użytkownik Paul Aurich
> <paul at darkrain42.org> napisał:
> > And Tomasz Sałaciński spoke on 08/25/2009 06:25 PM, saying:
> >> Hi,
> >> GKeyFile is an interesting choice, as you seem to use it only as a
> >>> hash table, with only one category.  Is there a particular reason you
> >>> did not use GHashTable?  The use of GKeyFile will be OK for Pidgin
> >>> 2.7.0, as it requires only glib 2.6, but it cannot be merged before
> >>> 2.7.0.
> >>>
> >>
> >> I use GKeyFile because it's more extensible - I can use it in the future
> for other things and it's very easy
> >> and clean to understand when you're reading the code. GHashTable lookup
> requires a valid pointer,
> >> which I can't pass to the ggp_send_image_handler function as this
> function is called by event triggered
> >> by libgadu, not libpurple.
> >>
> >> It works like this:
> >>
> >> 1. User sends message with images
> >> 2. Client A(Pidgin) sends the message and crc, name and size of the
> image to client B (original Gadu-Gadu client)
> >> 3. Client B sends gg_image_request event to client A - requests image
> with particular crc.
> >> 4. Libpurple handles this with ggp_send_image_handler, so associations
> between image id and crc32 need to be stored
> >> globally. I can't pass any pointer to this function. It just finds the
> crc and corresponding image id and sends the
> >> "data" section of image from the store.
> >>
> >> I can work around this by using a pointer array - if you have no problem
> with more than 11 variables in GGPInfo struct.
> >
> > Hmm, how is that different from what the code is doing currently using
> the
> > GHashTable pending_images?
> >
> > ~Paul
> >
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090826/9cc1ad55/attachment.html>