[sip-comm-dev] SIMPLE corrections


#1

Hi all,

A new correction has been commited concerning SIMPLE today. It may interest you, Joel and Ralph, as SC now use a clever solution (proposed by Ralph) to handle multiple status for a contact in PIDF documents.

I'll be very interested in any feedback with this new version.

Cheers,
Ben.

···

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


#2

Hi Ben,

I had a look at the implementation and I think it looks fine the way you
implemented it :slight_smile:

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?

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...

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.

Cheers,
Ralph

···

-----Original Message-----
From: Benoit Pradelle [mailto:ze_real_neo@yahoo.fr]
Sent: Saturday, October 27, 2007 5:30 PM
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] SIMPLE corrections

Hi all,

A new correction has been commited concerning SIMPLE today.
It may interest you, Joel and Ralph, as SC now use a clever
solution (proposed by Ralph) to handle multiple status for a
contact in PIDF documents.

I'll be very interested in any feedback with this new version.

Cheers,
Ben.

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

###########################################
CONFIDENTIALITY: This e-mail and any attachments are
confidential and may also be privileged.
If you are not the designated recipient, please notify the
sender immediately by reply e-mail and destroy all copies
(digital and paper).
Any unauthorized disclosure, distribution, copying, storage
or use of the information contained in this e-mail or any
attachments is strictly prohibited and may be unlawful.

###########################################
CONFIDENTIALITY: This e-mail and any attachments are confidential and may also be privileged.
If you are not the designated recipient, please notify the sender immediately by reply e-mail and destroy all copies (digital and paper).
Any unauthorized disclosure, distribution, copying, storage or use of the information contained in this e-mail or any attachments is strictly prohibited and may be unlawful.

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


#3

Hi ralph,

ralph.weires@hitec.lu a �crit :

Hi Ben,

I had a look at the implementation and I think it looks fine the way you
implemented it :slight_smile:
  
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.

Cheers,
Ben.

···

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