XSF Discussion - 2018-08-07

What is the rationle behind having xep368 throwing xmpp and xmpps SRV RRs into the same bucket anyway?

would it be possible to tune RSM to be able to retrieve content simply using page number and count ?

edhelas, by rewriting it to be something completely different, yeah

(not saying that this wouldn’t be useful in some cases)

hm

edhelas, or, if a service offers this, it could have a query mode where <after/> and <before/> refer to indices instead of keys

actually nevermind

edhelas, what is wrong with: https://xmpp.org/extensions/xep-0059.html#jump

that should be doing exactly what you want

multiply page size with number of page you want to calculate the index and you’re good to go ✏

jonasw, what if a service choose to user a smaller page size as requested?

or is the page size locked in at size point?

flow, you can then request more pages until you’ve got the amount of items you want

imagine a web view with a simple page number pagination

if the user chooses 100 items per page, but the service only provides 20, you simply have to fire 5 queries to fill the view page

so first RSM query woudl be with index=100*pagenumber, the subsequent four would be with <after/> based on the results of the respective previous query

Index support is optional though (and typically expensive).

yupp

jonasw "simply have to query", well it's not that simple

this means that you kinda have to cache the items while their coming, be sure that no new items came in between

having everything ready to handle the append of items, update the previous/next button to ensure that you can navigate to the other pages

and also you never know in advance what the server config is, so I cannot "prepare" my UI to request 25 items, the server can return 15 and I have to change my plans

edhelas, why not prepare the UI once you know how many items the page yielded?

after all, the query itself could fail too

so each time a user request a page, I need a first round to check then request the articles :)

edhelas, I was thinking more of: user action causes a new page request, issue the query, gather results, prepare UI

flow I have to see how I can refactor my flow to handle that more properly indeed

also I have to check how XMPP servers are handling that, ejabberd had RSM bugs a few months ago still, and I don't know how if Prosody and the others are implementing RSM

a nice compliance test would also be really awesome to build

the aioxmpp test suite starts to become something like that

publish 100 items, request them in many different way to see if they are consistant

publish a message archive, join a MIX, check if history replay works

disco items for a pubsub node with RSM, what do you think about it ?

or for any services basically

edhelas, isn’t that even a suggestion in XEP-0059?

makes sense to have

then ordering is also important

I'd like to ensure for Pubsub to disco the items based on the most recent first

(then I don't have to resolve the payload each time)

define most recent

most rcent isn’t a suitable key for RSM

well based of the "recent" definition in 0060 :p

https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-requestrecent

an RSM key (for use with <before/> and <after/>) must be an immutable property of the items which are enumerated

edhelas, eh, that’s for a node, not for a service

yes but the disco#items of a pubsub node should behave the same as a service afaik

or we have to specify that for a service it behave in a specific manner, alphabetically for example

but the XMPP server need to order by something before doing the limit/offset (for a SQL database)

and this need to be consistent between the XMPP servers, if not I can't rely on using disco#items with RSM in my client

(except by requesting everything and order the result locally…)

that’s what you have to do anyways

because in very few cases your users will want to sort by the name (as in, the @node value, not the @name) of the node

pubsub nodes can have hundreds of items, conference services thousands of rooms

yes

and sorting with RSM can only happen by primary keys

and the info is actually available on the xmpp server to sort a bit the things

(or unique, immutable keys at least)

<!-- disregard --> ✏