The problem is state management and caching in a distributed system XMPP ignores this problem completely. Missed updates to state are considered non-important. Message reliability does not fix this problem, as message reliability (or "guaranteed delivery") does not give you an absolute guarantee - what is really guaranteed is that a message will be delivered (probably with just once semantics) within a timeout period, and that the sender will have a mechanism of determining if the message was delivered within that timeout period.
With or without guaranteed delivery of presence, if state changes and the corresponding message times out (s2s down) or the state change does not result in a message being sent (coding error, server crash) state will stil become out of sync. Handling replay of state information peer-to-peer is a bad solution, as it makes things like s2s responsible for maintaining (or having access to) all presence state for all connections. Keep in mind also that presence isn't a single value per user; a user may publish multiple endpoints, may specify dynamic privacy rules to determine who is supposed to be given access to that presence, and may directly send different presence to specific entities (such as a MUC room). Requiring intermediaries to maintain or have access to this state also opens the door to manage state in other situations, such as MUC or pubsub. Routers become active participants in the protocol. The fundamental problem is 'what does a presence message mean'. In truth, it indicates the availability and status of an endpoint at a particular point in time. Over time, that presence message becomes next to meaningless. Unfortunately today, there is no mechanism within XMPP to even specify what time presence was set. There are solutions which come to mind, but none which closely resemble the current presence model in XMPP. -David Waite On Wed, 11 Aug 2004 11:33:43 -0700, Justin Karneges <[EMAIL PROTECTED]> wrote: > On Wednesday 11 August 2004 11:15 am, JD Conley wrote: > > the remote server. Thus, something like the proposed ping protocol > > would be required, not just a connection attempt. I've spent a great > > deal of time thinking about how to best fix this issue in our server and > > have come to the same conclusions as Justin. > > Unfortunately, 4 out of 5 council members have already objected to the JEP on > the council mailing list. This is probably some sort of record. The only > hold-out is rob, who told me this morning that he needs to read up on JEP-79 > (AMP) before he can form an opinion. > > That said, would it hurt for the council to write to the public standards-jig > so we can have an actual discussion? Better yet, can they _read_ it also? > It's not like this is a new topic, and we even have an active thread going. > > -Justin > > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > https://jabberstudio.org/mailman/listinfo/jdev > _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
