msimprpl status update

[Mark Doliner]

On Sat, 26 Jan 2008 21:15:19 -0800, Jeff Connelly wrote
> I focused on one important bug this week:
> http://developer.pidgin.im/ticket/4621 "MySpace IM causing program
> freeze at login attempt". I was able to reproduce it on Mac OS X and
> Windows, and isolate the problem to a full read buffer. Msimprpl
> previously used a 15 KB read buffer to receive incoming messages, but
> if you have a large number of buddies, the MySpaceIM servers will 
> send all their presence updates and status information in a message that
> was too large to fit in the fixed buffer. This should fail hard, 
> since I did check if there was no more space in the buffer and 
> signal a connection error if so, but a missing return statement 
> caused the program to continue execution to a while() loop where 
> msim_parse() was repeatedly called on the partial message, causing 
> the hang.
> 
> To fix this, besides adding the missing return statement, I extended
> msim_input_cb() to grow the read buffer if necessary, in the same way
> the IRC protocol plugin operates. I tested the change by logging onto
> an account with 262 buddies. The buffer grew in size once, and all 
> was well.

Hey Jeff, thanks for the status update (and the bug fixes!).  FYI the
im.pidgin.pidgin branch had multiple heads when I went to update a few minutes
ago, so I 'mtn merge'd them.  Apparently there were some conflicts in
libpurple/protocols/myspace/myspace.c as a result of your last 5 check-ins. 
It was mostly whitespace changes, and I think I got it all straighted out. 
Not really sure what happened there, but if you're working on the same code
from multiple computers you should try to commit to the same database, or just
'mtn push' after each check-in.

I'm not sure I merged this change correctly, so please double check the code
in trunk when you have a chance:
-     } else if (strstr(msg_text, "!!!ZAP_SEND!!!=RTE_BTN_ZAPS_")) {
+     } else if (strstr(msg_text, "!!!ZAP_SEND!!!=RTE_BTN_ZAPS_") == msg_text) { 

Anyway, the real reason for this email is to let you know about
PurpleCircBuffer.  It's a circular buffer for binary data that expands as
needed.  I didn't look at your buffer implementation in detail, but it seems
like PurpleCircBuffer might be useful to you.  Possibly more efficient, since
it doesn't need to move data back to the beginning of the buffer after a
partial read from it.  But because of this you would need to be careful in the
event that you need to do multiple reads from the buffer (if you read to the
end of the buffer and then need to wrap around to the beginning to continue
reading data).

You can see the header and implementation at libpurple/circbuffer.h and
libpurple/circbuffer.c

-Mark