> Date: Wed, 30 Sep 2009 13:16:46 -0600
> From: [email protected]
> To: [email protected]
> Subject: Re: [PubSub] Timestamp on items and versioning
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 9/30/09 1:09 PM, Robin Collier wrote:
>
> >>> 2 - That no two items published with the same item id can have the same
> >>> timestamp.
> >>> This takes care of the synchronization issue with regards to a retrieve
> >>> and notification
> >>> if an item has been replaced, since the combination of id and timestamp
> >>> now make
> >>> each instance of the item unique.
> >
> > Publishing an item with the same ItemID results in overwriting of the
> > old item, so I don't think we need to specify this rule.
> >
> >> Although in practice, the rule would probably not be necessary if stamps
> >> are at
> >> say, the millisecond level, since two published items with the same id
> >> are unlikely
> >> to have the same timestamp.
> >
> >> Without such a rule though, you can end up with the situation where;
> >> 1) Client subscribes
> >> 2) Client retrieves existing items.
> >> 3) Message arrives with an item ID that matches one from the retrieved list
> >
> >> Now, assuming the client actions the most recent item based on its ID,
> >> how do
> >> you tell which is the most recent?
> >
> >> Or if the order of events is important, there is no way to tell what
> >> that order is
> >> if you cannot rely on multiple events for the same item having different
> >> timestamps.
> >
> >> It means I can have an ON and an OFF event for some item (based on its
> >> id), but not
> >> know which came first, so I cannot determine the current state.
>
> Doesn't the service stamp the new (i.e., replacement) item when it is
> published? I don't see a need for any specification work here. If your
> service doesn't stamp the new item with the new timestamp, then file a
> bug report. If the timestamps are not fine-grained enough, also file a
> bug report. :)
>
As I said, in practice it should almost always be the case anyway (different
timestamps),
but I was thinking more along the lines of issues arising from say, a very busy
server
which has a backup of published items waiting to be processed (before being
timestamped). In this case, the same timestamp could inadvertently be used on
multiple
items (probably dependent on time granularity supported by language, OS and
hardware)
and since this does not violate the spec, then there is no need for an
implementation
to check against it.
There is no bug in this case, but the ordering problem still exists.
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrDrp4ACgkQNL8k5A2w/vzqVgCdEtnUw9laacOpvnBJhklUevmL
> nOIAn3F0II//ioikgfNuJ4YJXEjeGKUB
> =knWe
> -----END PGP SIGNATURE-----
_________________________________________________________________
Internet explorer 8 lets you browse the web faster.
http://go.microsoft.com/?linkid=9655582
