[sip-comm-dev] SIMPLE corrections
ze_real_neo at yahoo.fr
Thu Nov 1 17:24:27 CET 2007
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