Design and feature suggestions

[Evan Schoenberg]

On Mar 9, 2008, at 2:12 PM, Ethan Blanton wrote:

> This, I do not understand.  What makes you say the buddy list format
> is slow?  Are you aware of a situation where it matters, or is that
> just hypothetical?

I've certainly had problem reports from users who have extremely poor  
performance which end up being traced back to the blocking process of  
reading or writing out a very large blist.xml file.  I've specifically  
seen this happen in two instances:
  1. Users in an environment with a massive number of buddies, for  
example using a corporate Jabber server or a Sametime server which  
puts every employee onto the buddy list. Performance problems, of  
course, typically require the interface of this situation and a slow  
or overworked computer.
  2. Bizarre bugs.  In particular, recent versions of libpurple -- but  
not 2.4.0 so far as our testing shows so far -- could add MSN buddies  
to the blist.xml in duplicate with each connection cycle.  One user  
who was seeing this problem sent me a 7.4 megabyte blist.xml file  
which contained hundreds of 'copies' of the XML entries.  Clearly this  
is a bug outside the context of normal use, but it demonstrates what  
would happen if one truly did have that many buddies.

It'd be nice if computing the XML for and then  writing out the  
blist.xml file were nonblocking, but I have a difficult time  
envisioning this being handled in a threadsafe manner that wasn't  
nearly as costly as the problem itself.

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080309/33a204f9/attachment.html>