On Mar 31, 2009, at 2:48 PM, Peter Saint-Andre wrote:
On 3/31/09 4:41 AM, Pedro Melo wrote:
one of the issues that pops up now and again on this list is the
local
presence exploder (where the source system sends an individual
presence
to each contact) vs multi-cast presence (where each server sends a
single presence to each domain on the user roster, and the remote
server
explodes using a reverse-roster lookup).
Two questions:
Why should I trust the other server to do the right thing with
presence?
What if the presence states get out of sync?
Both question where discussed the last time this came up. My view is
still the same:
1) as much as you have right now: remote servers can do whatever they
want with your presence, you have no control after they leave your own
server (a pessimist would even say that you don't have any control
after they leave your client);
2) if subscription state gets out of sync, the protocol will behave
better or worse than the current version :), it really depends which
roster is correct. There was a thread 2 or 3 weeks back with a
tentative solution to keep subscription state in sync using the
initial <presence type="probe" />.
But let me clarify something: although the bandwidth and processing
savings of a multi-cast approach to presence distribution should be
relevant, I don't believe this is compatible with a lot of other
protocols that we have, so although I think multi-cast presence is a
worthy long-term goal, I don't think we are ready to address it at
this moment.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [email protected]
Use XMPP!
