[Standards-JIG] UPDATED: JEP-0059 (Result Set Management)

Ian Paterson ian.paterson at clientside.co.uk
Thu Jul 13 02:09:07 UTC 2006

> Updated implementation note to clarify handling of result sets (static vs. 
> dynamic). (psa)

Both the methods proposed by the implementation note have disadvantages that 
may prove significant in some cases:

1. Establish a "static" result set
- each result page was only correct at the time the first page was sent (as 
opposed to at the time the page itself was sent)
- requires responder to maintain a possibly very large state
- how long should this state be held if the pages are being requested 
slowly? (e.g. triggered by user interaction)

2. Generate a new "dynamic" result set
- omitted result items possible!! (Peter: this is not yet mentioned in the 
JEP's implementation note)
- duplicate result items possible
- *even if the above to errors do not occur, the complete result set 
returned would not necessarily reflect the result set as it existed at any 
one point in time
- for each page it is necessary to calculate (from start index) which item 
will be the first

An (optional?) addition to the protocol would enable another method that 
does not suffer from any of the disadvantages above (except *). Perhaps the 
responder could (optionally?) provide its opaque unique ordered ID of the 
last item whenever it returns a result set page. (If provided) this would 
allow the requestor to optionally specify the start of the next page using 
the ID instead of the <start/> element (the first returned element would be 
the one immediately *after* the specified ID).

For example, JEP-0055 responder implementors might choose to return the jid 
as the opaque ID:
    <set xmlns='http://jabber.org/protocol/rsm'>
      <last>woolly at sheep.com</last>

JEP-0055 requestor implementors could then use the opaque ID:
    <set xmlns='http://jabber.org/protocol/rsm'>
      <after>woolly at sheep.com</after>

- Ian

More information about the Standards mailing list