XSF Discussion - 2020-01-30

  1. flow

    larma, congrats to the 0.1 release of dino :)

  2. edhelas

    yeah, congrats 🎉 :)

  3. !XSF_Martin

    Happy release day 🎂

  4. marc


  5. rion

    Are there any time limitations for receiving iq result/error?

  6. Zash

    In theory not

  7. moparisthebest

    heat death of the universe

  8. Zash

    Not receiving a response is a protocol violation

  9. Ge0rG

    Zash: and therefore it can't happen!

  10. Zash


  11. Ge0rG

    rion: the real question is - what do you do with the iq result that arrives after you already went into the timeout handler?

  12. Ge0rG

    I think that we need to fundamentally change the semantics at the API layer, where you have a timeout only giving an indication that it's taking very long now, but not removing the actual response handler.

  13. Ge0rG

    OTOH, we had a handler leak in poezio just because of that

  14. rion

    Yep. it's what worries me. Assuming I have an app which runs for a very long time.

  15. rion

    And I mostly merge Psi+ to Psi. Only one patch left, which introduces the timeout

  16. Zash

    A recently added thing to track IQ stanzas in Prosody (sent by the server itself, not clients) has a default timeout of 2 minutes

  17. rion

    As far as I understand it has to be very use-case specific. For example for legacy FT a request can wait for a confirmation for hours if not days.

  18. rion

    Requesting conferences' list on slow connection sometimes takes ages. So everything is relative.

  19. rion

    But anyway, it would be nice to have some recommendations about timeouts in the standard and some XEPs

  20. moparisthebest

    it probably needs to vary wildly based on what you are doing

  21. rion


  22. moparisthebest

    if you are writing a system designed to talk over satellites it's going to need to be much higher than if you are developing a system to talk between servers on the same 10gbe network

  23. moparisthebest

    but yea, recommendations for "normal chat clients" would surely be a good idea

  24. jonas’

    timeouts are always wrong :(

  25. lovetox

    my idea is to not have timeouts

  26. lovetox

    for IQs, rather i pass the application a cancel handle

  27. lovetox

    The Application knows best when it does not make any sense anymore to process the response

  28. lovetox

    so it uses the cancel handle to remove the callback

  29. lovetox

    this is also important for if the user cancels the process , does not even mean the IQ did take long

  30. jonas’


  31. lovetox

    but if he opens some window that triggers fetching a list via IQ, and just closes it agian

  32. lovetox

    the application needs to remove the callback response

  33. jonas’

    for some automated tasks you’d still want timeouts though

  34. jonas’

    for example automated disco#info lookups

  35. jonas’

    you don’t want those to accumulate

  36. lovetox

    yeah ..

  37. lovetox

    probably timeouts do make sense in some situations

  38. jonas’

    in asyncio, you’d simply properly handle cancellation of the IQ request coroutine and thus allow the user to use asyncio.wait or something like that.

  39. moparisthebest

    but it sounds like you are saying your library makes timeouts the application's responsibility? which sounds like the right choice

  40. lovetox

    but for IQs you cancel the callback and you are fine

  41. lovetox

    more anoying is stuff like

  42. lovetox

    muc join

  43. lovetox

    where you have no way of tracking

  44. lovetox

    you cant cancel a muc join

  45. jonas’

    lovetox, you can send presence unavailable

  46. jonas’

    effectively removing yourself from the muc right after

  47. lovetox

    thats not a cancel

  48. jonas’

    you can’t cancel an IQ either

  49. lovetox

    no, but i can ignore it with simple dont listen for the callback

  50. lovetox

    and i know the id i have to ignore

  51. lovetox

    but with mucs, there is no id tracking

  52. lovetox

    the muc simply starts to spam me with presence, and even messages

  53. jonas’

    you track by from and presence type tho

  54. lovetox

    i have to start ignoring the whole jid

  55. jonas’

    yeah, and if a MUC does that, you reply with presence type="unavailable" and possibly message type="error"

  56. lovetox

    yeah, just saying i find it more annoying, i track now which mucs are in joining state, and if the user clicks abort

  57. lovetox

    i simply put the muc jid on the ignore list

  58. lovetox

    which is probably wrong

  59. lovetox

    because i could get invites from there

  60. lovetox

    i think i have the ignore list only for presence

  61. lovetox

    not for messages though

  62. lovetox

    but you are right, i should respond with presence unavailable

  63. lovetox

    but again only on the first presence i receive from that muc

  64. lovetox

    which again i have to track

  65. lovetox

    what would usefull is, if all join related messages, presence had a join-id attr like we have with mam the queryid attr

  66. lovetox

    but k muc is really old

  67. Ge0rG

    Every MUC is Schrödinger's Chat.