[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    [Kopete-devel] Re: Oscar groups and serverside contacts
From:       Christopher TenHarmsel <tenharmsel () staticmethod ! net>
Date:       2003-04-17 16:42:11
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 17 April 2003 12:33, Will Stephenson wrote:
> As I understand it, OscarSocket::parseSSIData reads a block of server side
> data and adds them to the aimbuddylist en masse.  After the whole block is
> parsed it emits gotConfig which (eventually) causes
> OscarAccount::addServerContact to be called for each buddy in the list.
>
> (Only considering buddies not already in the contact list now) this creates
> new kopete contacts, except if it couldn't find the named group for the
> numeric group id in the buddylist's known groups.  In which case it gives
> up without trying to make a new contact.
>
> This would never happen if the whole entire server side list was retrieved
> at once, as all groups would be known before addServerContact was ever
> called. But reading the debug output it seems that it arrives in several
> packets, which gives scope for contacts to arrive out of order.  Now your
> code in 0.6.x gets round this by having oscarsocket emit a signal from
> parseSSIData every time it reads a group, that causes queued groupless
> contacts to be reexamined as I mentioned below.  This mechanism is
> currently absent in oscar_split_branch.

Thanks for explaining this ^_^.  That make sense to me, I forgot that the code 
I wrote to add server side contacts drops them if the group doesn't exist.  I 
now remember thinking at the time that this wasn't a good way to go, so I 
think the thing to do is to put the queue back in there.  I can try and get 
to this this weekend...or wait, I can't because I can't even load protocol 
plugins due to very very new kdelibs.  Once that problem gets figured out I 
can try and fix this.

> What would be handiest for me is if you as a regular AIM user could have a
> look at what's done so far in oscar_split_branch and see what you think.

I think I remember how it was done, I remember seeing the queues, but being 
confused by why they were needed.  I think I assumed that the server sent 
things out in a logical order, but I suppose that was a bad assumption.

- -Chris

- -- 
Christopher TenHarmsel, KDE Developer
Public Key on www.keyserver.net
And I alone am returned to wag the tail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ntlmX4RAkQTBjgURAqhJAJ0cO5XOMMOtVUzT9gpmHkPvUQ27vwCfeEZU
f98XlE4+IQEbS/L2snJm+cQ=
=+9/D
-----END PGP SIGNATURE-----

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel

[prev in list] [next in list] [prev in thread] [next in thread]