> From: [email protected]
> Date: Thu, 19 Nov 2009 00:13:16 +0000
> To: [email protected]
> Subject: Re: [PubSub] versioning
>
> 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?
>
Give them both the same timestamp. I fail to see what the issue is
since the timestamps do not have to be unique for each item. That is
what the itemId is for. The only exception to this case is when the
item published has the same itemId within whatever degree of accuracy
you are using. Then you can simply increment the timestamp by 1.
> 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
_________________________________________________________________
Ready. Set. Get a great deal on Windows 7. See fantastic deals on Windows 7 now
http://go.microsoft.com/?linkid=9691818
