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

Peter Saint-Andre stpeter at jabber.org
Fri Jul 14 22:28:36 UTC 2006

Ian Paterson wrote:
>> 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'>
>      <max>10</max>
>      <start>0</start>
>      <last>woolly at sheep.com</last>
>    </set>
> JEP-0055 requestor implementors could then use the opaque ID:
>    <set xmlns='http://jabber.org/protocol/rsm'>
>      <max>10</max>
>      <after>woolly at sheep.com</after>
>    </set>

Well, there's no real reason for <start/> then, is there? In the first
request don't specify <after/>, in all other requests specify the unique
ID (UID) of the last item.

BTW, the problem of omitted items is not necessarily solved by this.
Consider what happens if the list is ordered:

1. I request and receive the 10 items on Page 1 (Items 0-9)

3. Dynamically-generated ordering adds a new Item 7a

2. In my next request I specify the UID of Item 9 in <after/>

3. I receive the second page with Items 10-19

But unless I go back to Page 1, I never see Item 7a.

Dynamic search seems to be ugly no matter how you slice it.


Peter Saint-Andre
Jabber Software Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060714/b000240b/attachment.bin>

More information about the Standards mailing list