XSF Discussion - 2020-09-27


  1. Holger

    MattJ, are the new MAM filter fields 'before-id' and 'after-id' exactly equivalent to RSM's before/after except that they're allowed to be combined?

  2. Holger

    MattJ, if so, couldn't the "server MUST return an item-not-found" thing be limited to those new fields, as clients who rely on that behavior could just use the new fields?

  3. MattJ

    Holger, so allow non-existent ids in RSM to proceed without an error?

  4. MattJ

    That would be a breaking change, no?

  5. lovetox

    and what would the server return Holger ? a complete=true?

  6. Holger

    > so allow non-existent ids in RSM to proceed without an error? Yes, as permitted by XEP-0059. It would be nice if generic XEP-0059 code could avoid special-casing MAM. > That would be a breaking change, no? I guess. Unless that MUST was added after the :2 bump?

  7. Holger

    (I think you didn't have it in earlier 0313 revisions, but I'm not sure at what point it was added and can't find it in the revision history.)

  8. lovetox

    Holger, but the item-not-found is not a special case for mam

  9. lovetox

    https://xmpp.org/extensions/xep-0059.html#notfound

  10. Holger

    Anyway if it was added before the :2 bump I see how it would be a breaking change, so it might just be an item for the next bump.

  11. Holger

    If you'd be fine with that change in general.

  12. Holger

    lovetox, that 0059 section allows servers to return an actual result if one of "the following circumstances" doesn't apply.

  13. lovetox

    sounds weird but yes it says "all circumstances must apply"

  14. lovetox

    hell knows why

  15. lovetox

    but what would you return?

  16. lovetox

    say you delete the database, i request the last mam-id which is invalid

  17. lovetox

    how would i get my latest messages?

  18. lovetox

    if you dont return an error

  19. Holger

    > The UID itself cannot be used to derive directly the next item within the set (e.g. the alphabetical or numerical order of the UIDs do not specify the order of the items). ejabberd has numerically ordered UIDs. If you request <after>42</after> it'll return the messages with UIDs >42.

  20. lovetox

    yeah you have, but thats just your implementation and ordering is not required

  21. Holger

    Sure.

  22. lovetox

    still if you reset your database

  23. lovetox

    you start with 1

  24. lovetox

    i request 1000

  25. lovetox

    what do you return?

  26. lovetox

    nothing? then i just lost messages

  27. Holger

    You ask me about my implementation and then you complain that I'm just talking my implementation 🙂

  28. Holger

    ejabberd's UIDs are timestamps. So nothing bad happens in your "reset DB" example.

  29. Holger

    But I don't think this is relevant.

  30. lovetox

    so what happens if i request mam-id=asd

  31. lovetox

    or are you saying you dont want to send an error in the specific case that you can determine a correct result?

  32. Holger

    XEP-0059 says "servers can do $foo if the conditions $bar apply". XEP-0313 says "servers must do XEP-0059 except that they can't do $foo even if the conditions $bar apply". That's the part I don't like.

  33. lovetox

    but in others where you not, you still would send an error

  34. Holger

    > or are you saying you dont want to send an error in the specific case that you can determine a correct result? Right. XEP-0059 says that.

  35. Holger

    > but in others where you not, you still would send an error Right.

  36. Holger

    lovetox, actually I seem to remember you arguing the other way round and liking my behavior because it avoids another MAM request 😉

  37. lovetox

    im not arguing for anything currently, i just wanted to understand your proposal

  38. lovetox

    at first i thought it was, send never an error

  39. MattJ

    Holger, can you take it to the list? Partly because I don't have the bandwidth to think about it today, partly because I don't want to forget you asked, and partly because I think other peoples' input would be good

  40. lovetox

    now i understand it, sounds good to me

  41. Holger

    MattJ, ok!

  42. MattJ

    I think if it weren't for backwards compatibility, this restriction would indeed not need to apply to RSM

  43. MattJ

    so if we can find some loophole or way to remove it, we probably can

  44. Holger

    MattJ, apart from this question; my understanding that `before-id` and `after-id` are equivalent to the RSM elements except for being combinable is correct?

  45. Holger

    I.e. I guess being able to combine them was the motivation to add them to 0313?

  46. lovetox

    i think equivalent is the wrong word

  47. lovetox

    before and after set in a rsm combined makes no sense, so no its not equivalent

  48. lovetox

    yeah if you think RSM is a filter and not a paging mechanism then it would be equivalent

  49. lovetox

    but its not

  50. Holger

    Right.

  51. Holger

    Yes yes I agree 🙂

  52. lovetox

    :D

  53. MattJ

    Holger: yes, being able to combine them was the reason

  54. Holger

    Ok, thanks!

  55. MattJ

    Since many people requested that and abusing RSM even further seemed like an undesirable path

  56. Holger

    Yup, makes sense.

  57. lovetox

    puh implementing vcard4 spec is .. challenging

  58. lovetox

    i would say its so complex that probably no one right now implements it in full

  59. lovetox

    and we are probably in a situation where one impl overwrites data that it does not understand

  60. MattJ

    lovetox: what problems do you face?

  61. lovetox

    i don’t yet, i just think its very much work to implement vcard4

  62. lovetox

    i dont think you can support a subset

  63. lovetox

    you have to implement the whole spec

  64. lovetox

    otherwise when you receive a vcard with properties and values you dont know, its very hard to "keep" them and push them again out, and only change some fields you support

  65. lovetox

    in vcard temp it was more like a simple key:value store

  66. lovetox

    with lets say 20-25 keys, so it was not hard to support all of them

  67. lovetox

    now you have various "parameters" for all the values, there are "groups" which group values

  68. lovetox

    im working on implementing this now, i keep you posted :)

  69. pep.

    lovetox: you'll need to support something like this for bookmarks2 anyway :p

  70. lovetox

    no pep. i dont think you can compare that

  71. lovetox

    in bookmarks2 there is a dedicated element which is an extension

  72. lovetox

    you save it away and you are finished

  73. lovetox

    in vcard this would be insanely more hard

  74. pep.

    lovetox: same issue when you start implementing extensions

  75. lovetox

    very theoretical discussion as there is not even one extension

  76. lovetox

    but yes 10 years, and 20 different extensions and you are halfway in vcard :)

  77. Zash

    What extensions to vcard-temp have there been?

  78. Link Mauve

    Zash, JABBER-ID was an extension compared to vCard 1 IIRC.

  79. Link Mauve

    I’m not aware of anything else.

  80. Zash

    Not sure that's the kind of extension lovetox was talking about?

  81. Link Mauve

    JABBERID* sorry.

  82. Link Mauve

    Ah, I only read the very last message before replying. :-°

  83. Link Mauve

    Probably not then.

  84. lovetox

    im not talking about extensions, pep. talks about extensions

  85. Zash

    JABBERID and DESC and whatever were additions compared to the never finished vcard xml variant of vcard3

  86. Link Mauve

    Right.

  87. lovetox

    im saying the vcard4 spec is big, supports many things, and i consider it very hard to support a subset

  88. lovetox

    without losing half the data on every update of course

  89. pep.

    well I already know of 1 non-standard one :x