[Iruka-devel] Iruka (IMCOM GUI)

[Erwan Loisant]

Hello.

I am still working on a GUI for Imcom. Imcom is a great basis to work so thank 
you for it ! However, we noticed some bugs.

A minor bug is a unix-specific line that could be changed to a more general one.

A more serious problem is the subscription system ; my co-developer propose a 
big modification, explainations are below (he did already code it, see diff).

Of course you are the developer of Imcom so it's your choice to integrate or 
not this change ; as they are not simple bugfixes we can understand if you 
refuse them.


Best regards,
Erwan
--

IMCom doesn't store subscription status for a contact.  It also doesn't store 
contacts on initial roster request, for which subscription status is 'none' or 
'from' (presence of this contact isn't visible for us).  And at last, it 
deletes a contact from in-memory representation when 'unsubscribed' presence 
received from him.  I really dislike this behavior and feel that a user should 
only be deleted from roster when server pushes roster entry with 
subscription="remove".

Consider following scenario (John is remote, Ben is IMCom's user):

  1) John removes Ben from his roster, sending him an 'unsubscribed'  presence.

  2) Ben's IMCom receives 'unsubscribed' presence and removes John from all its 
tables, but doesn't send remove-from-roster-iq to server (and it shouldn't in 
fact.)  Ben decides to remove John from his roster and sends 
remove-from-roster-iq to server.

  3) Server responds to Ben's remove-from-roster-iq and this respond is 
received by IMCom.  It tries to delete a user from internal tables again, but 
*BANG*!  He is already deleted from them and IMCom didn't check for this case.

Ok, you may say that it is a bug in IMCom.  But the entire way IMCom deals with 
subscriptions is slightly wrong, I feel.

How I wanted it to behave: user removing would occur only when 
subscription="remove" roster entry has been received from server.  And it 
should store all contacts, not only those, whose subscription status is 'to' or 
'both'  And it would be nice if IMCom allow us to know about 'ask' attribute 
value when jabber:iq:roster 'set' IQ, so we can differentiate between users 
pending for subscription and users with subscription 'none' or 'from'.
--

________________________________________
Université de Nantes, http://www.univ-nantes.fr

imcom-iruka.diff
Description: Binary data