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

Matt Mankins mankins at media.mit.edu
Tue May 20 21:49:44 UTC 2003

> >A similar solution could be crafted for pubsub.
> The example I have given in JEP0032 for sequence was not just plucked out of
> the air, 

Sorry, I've jumped into this game a little late.  I'll catch up soon. ;)  

My original message was spawned during implementation of JEP 0060, when
I noticed what I perceived to be a deficiency: I was unable to get a
subset of items from a node other than by limiting with max_items or 
fetching specific ids.  

I then suggested replacing max_items with a range approach, as I thought 
that was more general and encompassed max_items.

It was quickly pointed out that there were problems with my
suggestion--namely that item sequencing wasn't guaranteed to be consistent
and that publishes and deletes could happen at any time.

Rather than being didactic, my reference to IMAP was meant to offer a
historical solution to this class of range problems: the use 
of a "validity key" which changes whenever one of the inconsistency 
events occurs.  Instead of a range sequence being simply "1-10", it would 
be a tuple (validity key, start, end).

This works on the assumption that items will be published (added) more
often than deleted or updated.  A delete or update would invalidate the
client's range cache, whereas an add would not.  The first item in a node
would be sequence number one, the next sequence number two, 3, etc.  
Adding a new item would not change existing sequence numbers, whereas
updating or deleting would cause them to change, thus changing the
validity checksum.

I hadn't thought of sequences as being generally applicable at all, but
part of a very specific use for range requests only.  

I had something like this in mind, added to section 7.1.8:

Example 50. Request sequence 1 to 10 of node

<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" start="1" end="10"/>

Example 51. Server sends back matching items, along with validity for
future comparison.

<iq type="result" from="pubsub.jabber.org" id="items2">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <items node="generic/pgm-mp3-player" validity="12345">
      <item id="item2" sequence="1">
        <mp3 xmlns="mp3-ns">
          <song>Tuba Concerto</song>
          <artist>Edward Gregson</artist>
          <album>Tuba Tones</album>
      <item id="item3" sequence="2">
        <mp3 xmlns="mp3-ns">
          <song>Tuba Concerto</song>
          <artist>Walter Ross</artist>
          <album>The Tuba's Greatest Hits</album>

The client could watch the validity and if it's been modified, it will 
have to re-order the items/flush its cache.

Note that this is for a specific case: the client wants to look at just a
little bit of the items in the node.  If he wants a solid answer on all
the items in a node, he'll issue another request for everything.



More information about the Standards mailing list