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. 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? >> 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. /K
