On 3/5/12 2:21 AM, "Kevin Smith" <[email protected]> wrote:
> On Mon, Mar 5, 2012 at 9:08 AM, Joe Hildebrand <[email protected]> wrote: >>> duplicates. It's not clear to me that this isn't harmful. >> >> I don't see that as a large problem in pub/sub, since a later publish with >> the same ID replaces the previous publish. As long as the receiving server >> backs up enough to deal with reasonable clock skew, the worst case is a >> small number of republishes, which is usually going to be much better than a >> full synchronization, and is never going to be worse. > > This assumes that a client will need to keep a cache of the node's > items such that it can do duplicate elimination locally. This seems > icky, but perhaps it's the cost of doing business. Oh! Of course that's what I was thinking. The main use case I've got is large PEP nodes for long-lived stuff like vCards, ala XEP-292, section 5.2. > Are we sure there > are no edge cases in which a client will be unable to determine that > the stanzas are duplicates? Is there a way for the client to know how > much local caching it needs to do? No, I'm not positive, but I can't think of any, aside from poorly-written clients that shouldn't have sent the time in their presence. Don't correctly-written clients already need to match IDs for incoming notifications to catch updates? >>> The second is that there are many other times a pubsub service will >>> receive delay inside a presence, and this proposal could result in >>> duplication within a single stream. >> >> A) Let's change the namespace then. >> B) It may be that all of those times are at initial login, in which case >> there's no need to change the namespace. > > A) Yucky presence payload abuse - but again, maybe it's the cost of > doing business. It's not terrible, anyway, and I partly prefer this, > as it makes the behaviour opt-in. > > B) I don't think they are - there's autoaway stuff as well, at least. Oh, yeah. I had forgotten about that one. Ew. Ok, let's use a different namespace. Now, should we keep the time in seconds, or move to UTC? If we were UTC, and both sides had good time sync, you could actually be more accurate in matching, since network latency wouldn't matter. In practice, it's probably a wash. Number of seconds is likely less bytes and easier to program correctly. -- Joe Hildebrand
