XSF Discussion - 2018-08-07

  1. flow

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

  2. edhelas

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

  3. jonasw

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

  4. jonasw

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

  5. jonasw


  6. jonasw

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

  7. jonasw

    actually nevermind

  8. jonasw

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

  9. jonasw

    that should be doing exactly what you want

  10. jonasw

    multiply page size with number of page you want and you’re good to go

  11. jonasw

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

  12. flow

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

  13. flow

    or is the page size locked in at size point?

  14. jonasw

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

  15. jonasw

    imagine a web view with a simple page number pagination

  16. jonasw

    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

  17. jonasw

    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

  18. Holger

    Index support is optional though (and typically expensive).

  19. jonasw


  20. edhelas

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

  21. edhelas

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

  22. edhelas

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

  23. edhelas

    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

  24. flow

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

  25. flow

    after all, the query itself could fail too

  26. edhelas

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

  27. flow

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

  28. edhelas

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

  29. edhelas

    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

  30. edhelas

    a nice compliance test would also be really awesome to build

  31. jonasw

    the aioxmpp test suite starts to become something like that

  32. edhelas

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

  33. Ge0rG

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

  34. edhelas

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

  35. edhelas

    or for any services basically

  36. jonasw

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

  37. jonasw

    makes sense to have

  38. edhelas

    then ordering is also important

  39. edhelas

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

  40. edhelas

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

  41. jonasw

    define most recent

  42. jonasw

    most rcent isn’t a suitable key for RSM

  43. edhelas

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

  44. edhelas


  45. jonasw

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

  46. jonasw

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

  47. edhelas

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

  48. edhelas

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

  49. edhelas

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

  50. edhelas

    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

  51. edhelas

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

  52. jonasw

    that’s what you have to do anyways

  53. jonasw

    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

  54. edhelas

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

  55. jonasw


  56. jonasw

    and sorting with RSM can only happen by primary keys

  57. edhelas

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

  58. jonasw

    (or unique, immutable keys at least)

  59. jonasw

    or it is going to be rather expensive

  60. jonasw

    <!-- disregard -->