> Date: Wed, 30 Sep 2009 11:34:56 -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 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.
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.
>
> 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-----
_________________________________________________________________
Internet explorer 8 lets you browse the web faster.
http://go.microsoft.com/?linkid=9655582
