On 3/5/12 2:46 AM, Kevin Smith wrote: > 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.
WFM. I thought it might be easier to re-use iq:last because we already have that defined. However, it's unlikely that people would want to use last login time for synchronization operations other than pubsub (e.g., we already have one for MUC history, which is the other major use case I can think of), so a specialized extension for pubsub-since is fine with me... <presence from='[email protected]/balcony'> <since xmlns='urn:xmpp:pubsub:since' seconds='86511'> </presence> >> 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. Agreed, no strong preference here. Peter -- Peter Saint-Andre https://stpeter.im/
