On Tue, Jul 7, 2009 at 3:36 PM, Bob Wyman<[email protected]> wrote: > 2009/7/7 Matthew Wild <[email protected]> >> The other problem with timestamps was highlighted >> in the roster versioning discussions - timestamps are >> not unique (multiple items may be published by >> different people to the same node in under a second >> [or whatever time resolution you use]). > > Yes, This is a standard issue with timestamps. Nonetheless, timestamps work > fine for most applications -- with the caveat that there are occasional > issues with granularity. If you're really worried about it, then you end up > with a sequence number (like that used in rosters or the eTag of HTTP). But, > then you get into another set of issues that are just as troubling as those > with timestamps. For instance, if your system scales, you'll eventually need > to have different components processing messages and you won't want to > bottleneck them all through a single sequence number assignment component. > The result will be all sorts of problems with maintaining not only unique > numbers but ordered numbers... Moving from timestamps to ordered sequences > doesn't actually solve the problem, it only hides it in small systems. With > sufficient scale, timestamps and ordered sequences are pretty much the same > problem. So, why not just use a timestamp, make sure folk know about the > granularity issues, and do the simple thing. >
Perhaps I'm missing something, but what exactly is the "simple thing"? The way I see it this means you can end up with stale data thinking it is the newest available (you retrieve the data, someone later updates it within the same second). I don't see any simplicity in any workaround for that. Roster versioning has been changed to no longer use a sequence number. The version is now an opaque string which may be a version number, or a hash, or a UUID, etc. at the server's choosing. This approach allows absolute flexibility, for example you *could* still use timestamps if you wanted to. Matthew
