> Date: Tue, 29 Sep 2009 16:53:44 -0600
> From: [email protected]
> To: [email protected]
> Subject: Re: [PubSub] Timestamp on items and versioning
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
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.
> That seems reasonable to 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/
>
> iEYEARECAAYFAkrCj/gACgkQNL8k5A2w/vxZlwCguuLS/RuSbfhhO7wK2BACncHz
> KHUAoOf0mnIp2/zmXZcqI+dVWs3syTQP
> =Ikee
> -----END PGP SIGNATURE-----
_________________________________________________________________
Internet explorer 8 lets you browse the web faster.
http://go.microsoft.com/?linkid=9655582
