On 3/13/12 2:55 AM, "Sergey Dobrov" <[email protected]> wrote:
> On 03/13/2012 12:52 AM, Joe Hildebrand wrote: >> >>> Another still uncovered thing is how to determine missed notifications >>> in the case of connection failures. >> >> This is really an implementation detail of how the client sets the time in >> the ago. >> > > Sure. But how it's suggested to the client to track such cases? The > client can't know when it's connection was broken but can set the "ago" > since the time last packet was received. But there's definitely no way > to detect if events were intercepted by another resource. I don't care if the events were intercepted by another resource. All I care about is the last stanza I received, or the last successful ping, or the last successful XEP-198 synchronization. The suggestion will be that you take that time, subtract from the current time, then add the longest end-to-end latency in your network, say 2 seconds as a default. Worst case, you'll get a couple of re-notifications for notifications that were in flight at the time you disconnected. > Actually, it's > not clear how pubsub service will receive the presence in case of pubsub > (and not presence) subscription. PEP. > And again the XEP will have problems with from/to subscription states.. No. PEP. It only really works with subscription='both'. -- Joe Hildebrand
