On Mon, Mar 5, 2012 at 9:37 AM, Joe Hildebrand <[email protected]> wrote: > On 3/5/12 2:21 AM, "Kevin Smith" <[email protected]> wrote: >> 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.
Ah. It suddenly makes much more sense to me. >> 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? I think it depends on the type of node. Notification-only nodes, I wouldn't have thought so (and getting 'duplicates' there seems to be a bad thing, potentially). > Oh, yeah. I had forgotten about that one. Ew. Ok, let's use a different > namespace. OK. > 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. I think the problems are broadly similar with both. /K
