[standards-jig] Re: [JDEV] PubSub (0060) Max_items -> Range?

Matt Mankins mankins at media.mit.edu
Tue May 20 14:18:00 UTC 2003


Hi,

> This is a valid point, but what if the subscriber does not know how many
> have been missed?

This seems to be a client side issue.

Since the items are unique and don't change over their lifetime, one 
could imagine an algorithm like this:

current = 1

while (1)
{
 
 items = get_items_from_node(current,current + page_size) # range="1-10"

  for all items 
  {
   if (item_in_cache(item_name))  #item_name is unique
     up_to_date = 1
     break while loop
   else
     add_to_cache(item)
  }

  # try next page
  current = current + page_size + 1
}    

...which should keep the client up to date.

Note too that the JEP suggests that max_items="2" return the two *most 
recent* items...so there already exists a counting, done by time.


> A  subscriber may re-subscribe after an enforced/unplanned outage and wish
> to get back up to date. It does not know how many events it has missed. Time
> does not solve it (for what is...time?). For pubsub to be functional it
> needs a form of sequence numbering and, thus, gap filling, an example of
> which was proposed in JEP0032.


I'm not sure we need an additional form of sequence numbering, for as long 
as the client consistently orders the node, it should be ok.  I think the 
current convention of FILO is a practical one and should be followed.

Best,

Matt Mankins

> On 19/5/03 7:39 pm, "Matt Mankins" <mankins at media.mit.edu> wrote:
> 
> > 
> > In thinking about client interaction with pubsub nodes today I realized
> > that it might sometimes be useful for clients to request a range of items
> > from a node (this is modified example 50):
> > 
> > <iq type="get" from="pgm at jabber.org" to="pubsub.jabber.org" id="items2">
> > <pubsub xmlns="http://jabber.org/protocol/pubsub">
> >   <items node="generic/pgm-mp3-player" range="10-20"/>
> > </pubsub>
> > </iq>
> > 
> > We have max_items already, which suggests:
> > 
> > "When max_items is used, implementations SHOULD return the N most recent
> > (as opposed to the N oldest) items."
> > 
> > ...so there already exists a notion of "counting" to the items.
> > 
> > Range requests would be useful for low-bandwidth clients as well as for
> > high-volume nodes.
> > 
> > Since range is actually more general than max_items, it might be
> > preferable to replace max_items with range.  ie-- range="0-10" would be
> > equivalent to the current max_items="10".
> > 
> > 
> > 
> > Matt Mankins
> > MIT Media Lab
> > http://www.media.mit.edu/~mankins/




More information about the Standards mailing list