[Pidgin] #13223: Blocking of ICQ contacts is impossible

[Pidgin]

#13223: Blocking of ICQ contacts is impossible
---------------------+------------------------------------------------------
 Reporter:  notgary  |        Owner:  MarkDoliner
     Type:  defect   |       Status:  new        
Milestone:           |    Component:  ICQ        
  Version:  2.7.3    |   Resolution:             
 Keywords:           |  
---------------------+------------------------------------------------------

Comment(by dustin):

 That's a duplicate to tickets #9034, #9111, #12549, #12933, IMHO.

 I spent some time trying to figure out what is happening there, see

 [http://pidgin.im/pipermail/devel/2010-October/009890.html],

 [http://pidgin.im/pipermail/devel/2010-October/009890.html] and follow-
 ups.

 On some accounts, there are SSI entries -- i.e. (bid, gid) pairs -- stored
 on the server that will not be transmitted to pidgin/libpurple.

 When pidgin tries to use the same (bid, gid), it gets the "item already
 exists" error as reply.

 I originally suggested deleting those broken/phantom entries from the
 server, but now I think this wouldn't be such a good idea:

 1. libpurple would have to keep track of the (bid, gid), because the error
 message does not contain this information.

 2. I recently observed those broken entries sometimes come back after
 changing the user info (using pidgin), so there might actually be some
 real information behind them.

 (Also sipulka reported similar behaviour after changing the profile
 through the web interface
 [http://developer.pidgin.im/ticket/9034#comment:22].)

 Although there's a possibility that pidgin contributes to those errors
 (e.g. by sending incomplete data), it's basically (very likely) a bug of
 the server.
 Therefore I suggest a simple cover-up:

 The bid count could as well start at 0x0030 instead of 0x0000 (patch as
 attachment).

 On login, the server announces ssi rights for entry types 0x0000 to
 0x002e.
 I guess this can be taken as an indication of how many entries the server
 possibly may want to occupy, and we can safely start above this number.

 Besides, this wouldn't be much different from leaving out occupied group
 IDs, which is already done because of the same bug.

 In case this does not work, one could still look for a more serious fix
 for the problem.

 NB:
 Other clients do not have this problem, but that's because they pick
 random bid numbers, instead of ascending numbers as libpurple does.
 This makes bid collisions very unlikely.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/13223#comment:1>
Pidgin <http://pidgin.im>
Pidgin