rionAre there any time limitations for receiving iq result/error?
ZashIn theory not
moparisthebestheat death of the universe
ZashNot receiving a response is a protocol violation
Ge0rGZash: and therefore it can't happen!
Ge0rGrion: the real question is - what do you do with the iq result that arrives after you already went into the timeout handler?
Ge0rGI 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.
Ge0rGOTOH, we had a handler leak in poezio just because of that
rionYep. it's what worries me. Assuming I have an app which runs for a very long time.
rionAnd I mostly merge Psi+ to Psi. Only one patch left, which introduces the timeout
ZashA recently added thing to track IQ stanzas in Prosody (sent by the server itself, not clients) has a default timeout of 2 minutes
rionAs 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.
rionRequesting conferences' list on slow connection sometimes takes ages. So everything is relative.
rionBut anyway, it would be nice to have some recommendations about timeouts in the standard and some XEPs
moparisthebestit probably needs to vary wildly based on what you are doing
moparisthebestif 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
moparisthebestbut yea, recommendations for "normal chat clients" would surely be a good idea
jonas’timeouts are always wrong :(
lovetoxmy idea is to not have timeouts
lovetoxfor IQs, rather i pass the application a cancel handle
lovetoxThe Application knows best when it does not make any sense anymore to process the response
lovetoxso it uses the cancel handle to remove the callback
lovetoxthis is also important for if the user cancels the process , does not even mean the IQ did take long
lovetoxbut if he opens some window that triggers fetching a list via IQ, and just closes it agian
lovetoxthe application needs to remove the callback response
jonas’for some automated tasks you’d still want timeouts though
jonas’for example automated disco#info lookups
jonas’you don’t want those to accumulate
lovetoxprobably timeouts do make sense in some situations
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.
moparisthebestbut it sounds like you are saying your library makes timeouts the application's responsibility? which sounds like the right choice
lovetoxbut for IQs you cancel the callback and you are fine
lovetoxmore anoying is stuff like
lovetoxwhere you have no way of tracking
lovetoxyou cant cancel a muc join
jonas’lovetox, you can send presence unavailable
jonas’effectively removing yourself from the muc right after
lovetoxthats not a cancel
jonas’you can’t cancel an IQ either
lovetoxno, but i can ignore it with simple dont listen for the callback
lovetoxand i know the id i have to ignore
lovetoxbut with mucs, there is no id tracking
lovetoxthe muc simply starts to spam me with presence, and even messages
jonas’you track by from and presence type tho
lovetoxi have to start ignoring the whole jid
jonas’yeah, and if a MUC does that, you reply with presence type="unavailable" and possibly message type="error"
lovetoxyeah, just saying i find it more annoying, i track now which mucs are in joining state, and if the user clicks abort
lovetoxi simply put the muc jid on the ignore list
lovetoxwhich is probably wrong
lovetoxbecause i could get invites from there
lovetoxi think i have the ignore list only for presence
lovetoxnot for messages though
lovetoxbut you are right, i should respond with presence unavailable
lovetoxbut again only on the first presence i receive from that muc
lovetoxwhich again i have to track
lovetoxwhat would usefull is, if all join related messages, presence had a join-id attr like we have with mam the queryid attr