[standards-jig] FW: [Re: retracting JEP-0040?]
jabber.org at ralphm.ik.nu
Mon Jun 9 12:26:06 UTC 2003
On Tue, Apr 29, 2003 at 08:46:36PM -0500, Peter Saint-Andre wrote:
> ----- Forwarded message from Timothy Carpenter <> -----
> Subject: Re: retracting JEP-0040?
> From: Timothy Carpenter
> To: Peter Saint-Andre
> I have a few thoughts, basically in the area of functionality or behaviour
> in JEP0040 that are not covered by JEP0060.
> 1) there seems to be no ability to request a snapshot of the full contents
> of a node at the point of subscription.
> 2) The area of ID is still undefined, yet this is important to define. I
> added a separate element, publish type, to control if the event was
> updating, contained a full list of all current items in the node, was
> correcting it (as opposed to altering it) etc. An alteration due to an event
> needs to be distinguished from an alteration because value(s) are wrong.
> This may not matter in chat, but is very important when sending financial
> 3) Sequence numbering (the main thrust of JEP0040) is not covered. Being
> able to ask for 'n events' in the past is not comparable, and relying on a
> free format ID to control order and gaps is also not suitable in all cases.
> As such, I believe that JEP0040 does not cover the same areas as JEP0060,
> but I would like to suggest that the purpose of JEP0040, a robust version of
> pubsub, be converted into an extension built upon JEP0060 foundations.
It's been a while since this came by, but I was thinking about Gap Filling
and pub/sub and remembered this JEP.
Most of the stuff in JEP-0040 could indeed be adjusted to fit JEP-0060 instead
1) JEP-0060 already defines a way to request a snapshot of the full
contents of a node in section 7.1.8:
<iq type="get" from="pgm at jabber.org" to="pubsub.jabber.org" id="items1">
This returns a list with, for each item in the node, the last publish
to that item in that node. This of course assumes each publish is a
complete replacement of a certain item. If you would want to have
for example incremental updates, you could have some sort of hierarchy
in the item id. For example: 'item/1' 'item/2', 'item/3', where item/* all
belong to the same logical item.
2) Doesn't this kind of information belong in the payload?
3) Sequence numbering
As JEP-0060 does not allow for subscribing to a publisher and the original
publisher of an item is not relayed in the notifications, we probably only
need one sequence here. This would be a sequence per node, increasing upon
each publish. There should be a way to request the items in the gap,
by extending the <items/> element with 'start' and 'stop' attributes
that have the sequence numbers as value.
At one moment I thought about JEP-0059 (Limiting and Paging Extension),
but I thought it was too verbose.
More information about the Standards