Ok, that is realy the answer for using 'ver' instead of timestamps, true and thanks. Should be seen there, I was thinking too much from algorithmic point of view forgetting some realities :)
All the rest from my post, I still agree with that 'ver' should be able to placed by publisher and this feature must be optional. Reasoning for Service to generate 'Ver' exists, and that is good for sure for many cases. My main point being there exists also reasoning and use cases to allow publisher to set 'Ver' Ville On Thu, Nov 19, 2009 at 2:13 AM, Matthew Wild <[email protected]> wrote: > 2009/11/18 Ville Varis <[email protected]>: > > Hi, > > > > That really sounds great to have there, willing to give one point for > this > > one here and now. > > > > The following would require (by me) at least the option to allow publiser > to > > set version number for item, and to get the error if ItemId,'Ver' is not > > Uniq. > > "The value of the 'ver' attribute MUST be generated by the service, not > > accepted by the service in the published item." > > > > This would make the trick here, just as the timestamp would do, and > really > > cannot see the big difference between 'ver' or 'timestamp' there now, as > > both are planned to be generated by Service. > > > > Generation by service would not guarantee that into the level where I can > as > > subscriber swap from one feed source to other similar one (namely from > > server1 to server2 for node "my/interest") with subscribing only the > items > > after the 'ver=xxx"' > > > > The very same comes to problem to solve the case "should I update this > item > > from secondary feed or not", being same feed subscribed from two servers. > > With service creating the 'Ver' or Timestamps, the subscriber can't know > > which update is the lates ones, when must believe it to be the one > received > > last. (timestamp can go close to it, but due to different processing > times > > and laod that cannot trusted, and very same feed should be able to set up > > from cracth with the log file/log DB at any time anyway) > > > > With stamp set by publisher, if publisher does in right, the two or more > > feed for the same thing can be used and so the subscription quality and > > failover capability ensured. > > > > From publisher point of view, two identical feed is impossible to create. > So > > Server1 and Server2 cannot hold _exactly_ the same feed when it comes to > > ItemID, 'Ver' pairs. (which is requirement to algorithm above) > > > > As well, in the service level (may be later in XEP-0060) the circular > > pub/sub nodes subscribing each others, offering the same feed for their > > subscriber can be created (homeworks :)) > > > > Succesfull need of use for 'ver' described above would require the > 'retract' > > messages to hold the same 'ver', and service to keep the retracted items > as > > answers for those who will subscribe the items after 'ver'=xxx, the time > or > > number of the retracts should be configuratable through the service. > > > > So, really, my 2 cents. I can't find what is to be solved by this 'Ver' > over > > the timestamps, there might be som just not getting it in my mind now. > > > > Quite simple... what happens if you publish 2 items in one second? or > one millisecond? or whatever accuracy you take it down to? > > Having an opaque ver tag allows one to use timestamps if accuracy is > not a problem. > > Having the server decide the ver tag allows for some flexibility in > how it is generated. For example different nodes of a cluster may > prefix it with their id to make sure the ver is unique. If the client > supplied the ver, the node would need to check with all the other > nodes (or just the 'master' copy, if there is one) whether this > particular ver had already been used. This sort of scalability was > cited as an issue by some people, so it's wise to allow for it. > > Note: 'node(s)' in the previous paragraph refers to server cluster > nodes, not pubsub nodes - just in case :) > > Matthew >
