Design and feature suggestions

[Ethan Blanton]

Evan Schoenberg spake unto us the following wisdom:
> 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:

I agree that this can happen, but this isn't really related to the
buddy list format.  If we were using a database, libpurple would just
sit and spin on database updates instead of building (parsing) an XML
tree. Whether or not that database spin was any faster than building
the XML tree would depend entirely on other factors.  Put the database
on !localhost, for example, and ... ;-)

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

Particularly a computer with saturated I/O.

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

Again, this is not something which I foresee being magically fixed by
a database backend.

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

This, on the other hand, would be a *real* improvement, and it is
entirely orthogonal to the issue of whether our configuration data is
stored in flat files or a database.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080309/201ec87c/attachment.sig>