[jdev] Re: Reliable presence

[Peter Saint-Andre]

In article <3eb0429d04081118594babed3a at mail.gmail.com>,
 David Waite <dwaite at gmail.com> wrote:

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

There are solutions, yes. But personally I don't see this as a major 
problem right now -- we seem to be usually talking about edge cases 
rather than use cases that are central to building out XMPP. Others are 
of course welcome to work on this, but I'm not going to spend a lot of 
cycles on it until I see some powerful use cases.

/psa