XSF Discussion - 2020-01-30

larma, congrats to the 0.1 release of dino :)

yeah, congrats 🎉 :)

Happy release day 🎂

🍾

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

In theory not

heat death of the universe

Not receiving a response is a protocol violation

Zash: and therefore it can't happen!

Correct!

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

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.

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

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

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

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

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.

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

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

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

Agree

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

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

timeouts are always wrong :(

my idea is to not have timeouts

for IQs, rather i pass the application a cancel handle

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

so it uses the cancel handle to remove the callback

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

true

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

the application needs to remove the callback response

for some automated tasks you’d still want timeouts though

for example automated disco#info lookups

you don’t want those to accumulate

yeah ..

probably timeouts do make sense in some situations

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.

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

but for IQs you cancel the callback and you are fine

more anoying is stuff like

muc join

where you have no way of tracking

you cant cancel a muc join

lovetox, you can send presence unavailable

effectively removing yourself from the muc right after

thats not a cancel

you can’t cancel an IQ either

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

and i know the id i have to ignore

but with mucs, there is no id tracking

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

you track by from and presence type tho

i have to start ignoring the whole jid

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

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

i simply put the muc jid on the ignore list

which is probably wrong

because i could get invites from there

i think i have the ignore list only for presence

not for messages though

but you are right, i should respond with presence unavailable

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

which again i have to track

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

but k muc is really old

Every MUC is Schrödinger's Chat.