-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/30/09 1:54 PM, Robin Collier wrote: > > >> Date: Wed, 30 Sep 2009 13:16:46 -0600 >> From: [email protected] >> To: [email protected] >> Subject: Re: [PubSub] Timestamp on items and versioning >> > 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.
OK, you've convinced me. :) 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/ iEYEARECAAYFAkrDvj8ACgkQNL8k5A2w/vxDPQCgz8NDqOkPlzwn5WKsEP5LFblB nfgAoOEKD1kBWdqL4ctzgH3BLEEwcal1 =ajqE -----END PGP SIGNATURE-----
