-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/30/09 11:29 AM, Robin Collier wrote: > > >> Date: Tue, 29 Sep 2009 16:53:44 -0600 >> From: [email protected] >> To: [email protected] >> Subject: Re: [PubSub] Timestamp on items and versioning >> > On 9/17/09 10:36 AM, Robin Collier wrote: > > >>> Date: Wed, 16 Sep 2009 16:34:08 -0600 >>> From: [email protected] >>> To: [email protected] >>> Subject: Re: [PubSub] Timestamp on items and versioning > >> On 7/8/09 10:25 AM, Robin Collier wrote: > >> [wow, your mail client does strange threading] > > >> ------------------------------------------------------------------------ >>> From: [email protected] >>> To: [email protected] >>> Date: Tue, 7 Jul 2009 15:13:23 -0400 >>> Subject: Re: [PubSub] Timestamp on items and versioning > >>> Do you have some specific need for generic time stamps on all PubSub >>> items regardless of context? > >>>>> > I gave several reasons for its inclusion in the original >> request, so I >>>>> > will just link to it here >>>>> > <http://mail.jabber.org/pipermail/pubsub/2009-May/date.html>, >>>>> > where the original thread started. >>>>> > >>>>> > In addition to what was listed in the original thread, it can be >>> used to >>>>> > synchronize the >>>>> > order of actions when doing a get items and an item from the >> same node >>>>> > is deleted. >>>>> > There is no way to currently know if the same item received in >> the get >>>>> > has actually >>>>> > been deleted or not. > >> Given that you're interested in timestamps on items that are retrieved >> after the fact, it's not clear to me why a delayed delivery notation >> (XEP-0203) would not solve the problem. There are examples of this in >> XEP-0060. > > >>> That only works on notifications, and even then is only appropriate >> when >>> there is only a single <item> since it applies to the contents of >> <items> as >>> a whole. To work on a list of items being returned from a request, >> it would >>> have to be included with each item, which the current schema for >> item does >>> not allow. > > I see your point. > > So something like this: > > <message from='pubsub.shakespeare.lit' > to='[email protected]'> > <event xmlns='http://jabber.org/protocol/pubsub#event'> > <items node='n48ad4fj78zn38st734'> > <item id='i1s2d3f4g5h6bjeh936' > publisher='[email protected]' > stamp='2003-12-13T23:58:37Z'> <<<<<======== > <geoloc xmlns='http://jabber.org/protocol/geoloc'> > <description>Venice</description> > <lat>45.44</lat> > <lon>12.33</lon> > </geoloc> > </item> > </items> > </event> > </message> > > >> That looks good. I would also add two rules regarding timestamps. >> 1 - They are created by the service, not the publisher
Yes. Indeed, if the publisher includes a timestamp the service will just throw it away and generate its own timestamp. >> 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. 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/ iEYEARECAAYFAkrDlsAACgkQNL8k5A2w/vyRcACfdrdD8eSO/yBOftCadSkApIvD yUYAnR9J32X31iF0719NJNze+P0Kqs4N =14wd -----END PGP SIGNATURE-----
