-----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. :) 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-----
