[sip-comm-dev] SIMPLE corrections

Benoit Pradelle ze_real_neo at yahoo.fr
Thu Nov 1 17:24:27 CET 2007

Hi ralph,

ralph.weires at hitec.lu a écrit :
> Hi Ben,
> I had a look at the implementation and I think it looks fine the way you
> implemented it :)

Thank you for the time you spent in reviewing all the changes !

> Some small questions/comments:
> 1) It took me a little time to understand the setStatusForContacts()
> method. But just to make sure I got it right: In the end, the
> newPresenceStates Vector which collects the contact state modifications
> makes sure that it contains never more than one single entry for a given
> contact, right?

It's absolutely right. This function is the the core of the way SC now 
handles priority and multiple statuses, at anytime in this function, the 
Vector contains the list of the contacts concerned by the read part of 
the presence doc and their preferred state to use. By preferred I mean 
the status with the best availability among all the highest priority 
statuses for this contact. So there is never more than one preferred 
state for a contact.

> 2) if I'm right with 1), does the comment at line 3985
> (newPresenceStates is ordered so priority order is respected) make
> sense? This confused me a little... Does the order of the vector
> elements really matter (at this point)? The given states in
> newPresenceStates will be changed now for all contained contacts in any
> case, so does it really make a difference in which order this happens?
> Perhaps I'm just missing something...

It's just an interpretation I've made of the RFC: "Applications SHOULD 
handle contacts with a higher priority as they have precedence over 
those with lower priorities." so I tried to prioritize at the maximum 
all the contact handling procedures. If by any reason, the server wants 
us to contact first one address, and express it by affecting an higher 
priority to a contact, we'll respect it.
I'm ok with you: it'll be probably never been used and the cases a 
server need this are probably too exotic to happen but, I preferred to 
add it just in case of...

> 3) I think the iteration at lines 3763-3777 doesn't make much sense,
> does it? The way it is now, that iterator runs on sipcontact, which is
> always an empty vector at that point.

That's exact, it's now corrected. Thanks for reporting it.


To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net

More information about the dev mailing list