XSF Discussion - 2018-11-04

so I’m thinking about the case where SM resumption fails, but the server gives me an ``h`` value in the <failed/> stanza (as allowed in XEP-0198).

I’m not sure what to do with this information, as a library.

I can of course mark all unacked stanzas covered by the h value as acked

that probably makes sense unconditionally

does it also make sense to automatically re-send stanzas which have not been acked?

I tend to "no, because we don’t know what happened in the meantime and the application should re-sync state and re-send whatever it wants to re-send"

i.e. treat the stanzas as "lost" and attach a clear error to their tracking handle.

hm that would be rather bad in my opinion

imagine a mobile use case, where the SM timeout is 5 minutes

what would be "bad"?

so all messages i send after 5 minutes when im currently offline, get a error

and i have to retype them?

of course not

your client would have a resend button

or may even resend them automatically

question is, what should the *library* do

if you think there is a case where a client does not want to resend them you have to implement this option

I don’t think that resending by default is the safe way

whats unsafe?

(note: not insecure, but unsafe)

for example, a presence stanza sent to a MUC

which changes your nickname

no, bad example, you’d await an ack for htat

but you get the idea: state was lost, and stanzas were queued under assumption of state which was lost.

I think re-sending those stanzas under a different state isn’t safe

does the lib hold the stanzas or the client?

the lib

it has the outbound queue where unacked stanzas are kept until they are acked

then you provide the stanzas, and he can sort stuff out he doesnt want to be resent?

that’s kinda what happens when I mark them as failed

as a client dev, i would disable all functionality in the client except sending messages

to circumvent any complicated problems

the most important thing is sending a message

everything else, like changing a nick or stuff like that, can wait until the user is online

> as a client dev, i would disable all functionality in the client except sending messages

that statement is confusing

i mean message from the standpoint of the user

not from the protocol

you mean while offline?

yes

right

but you don’t know immediately that you’re "offline"

dont i? gajim seem to know it pretty soon ✏

usually after the first stanza

depends on the failure mode

right, and that first stanza could be whatever action the user triggered

also, I’m not sure that blocking most of the UI on intermittend network failures is a good thing

Gajim blocks all UI, you cant even write messages ^^

meh

i agree its not good

but it needs a lot of work to cache all message, make good ui for it, so the user sees whats sent and what not etc

and then you still have to think alot about the things you just thinign now

indeed

have to go, see you later

gl

jonas’, smack das also resend unacked stanzas on resumption FWIW

flow, on failed resumption?

note that this is all about failed resumption.

yes, alswas

IIRC

huhm.

I see the issues you mentioned, but one has to weight it against the advantages

I think this conflicts with the state resync which aioxmpp (i think correctly) does after a failed resumption too much to do this by default

although it could be interesting to auto-resend stanzas after everything else has reported that state has been synced (e.g. MUCs rejoined)

but that would give things even more time to diverge unknowingly…

hmm, also sounds like to much complexity for a minor/very rare/(non existent?) issue

yeah, I also don’t think this is a good idea

I think I’ll go the route of: resumption failed? -> mark acked stanzas as acked, mark unacked stanzas as failed and let the application/services deal with it

because that’s the only way I can provide clear guarantees to the using code

and aioxmpp is all about clear guarantees

now I wonder what the code really does on failed resumption, let me check

yeah, smack does simply resend in every case

ok

I’ll go with "make unacked stanzas fail"

this makes "failed resumption without @h" just a special case of "failed resumption with @h", which is conceptually very nice.

and provides consistency.

jonas’ [12:10]: > I’ll go with "make unacked stanzas fail" That's a good approach. In yaxim, I'm re-sending all messages that are pending, after a reconnect. But obviously only proper messages

Ge0rG, so no presences? how do you prevent lost presence updates?

by remembering the last presence and resend it on reconnection/failed resumption?

flow: when resumption fails, you need to redo all presence anyway

flow: I'm sending presence from the client preferences on connect

ok, nice idea, so on failed resumption you filter messages stanzas out of the list of pending stanzas and only send those

that could work

and on successfull resumption one could remove all but the last self-presence stanza, although that optimization probably won't give you much in most cases

on successful resumption, you don’t need to do anything

you don't need do, right

ahh, I see, you want to CSI-style collapse multiple queued outbound stanzas

yeah, just some premature micro optimization that nobody should do client side :D

heh

bbl

gl

The issue with that is that you need to fix the counters. There is a big chance to f* it up.

you don’t need to fix counters for stanzas of which the server said it didn’t receive them upon resumption ✏

So I sent my application for Board. Please wish me lucky stanzas!

\o/

so we’ll at least have a competition for board this year...

Link Mauve, https://wiki.xmpp.org/web/index.php?title=Emmanuel_Gil_Peyrot_for_Council_2018&action=edit&redlink=1

Very healthy indeed!

well, maybe. ralphm and arc still need to do their applications.

Seve, sounds great :)

By the way, last time I think I also had the same problem. Not sure if it was me or some kind of cache. My application link still appears in red colour. Do you remember what was it, jonas’? I feel you were also in the discussion last time I mentioned that.

yes, that’s some caching

I think there’s a magic thing you can say to mediawiki to purge the caches, or you just wait

there we go

append ?action=purge to the URL

Woah, lovely! Saving that for next time, thanks, jonas’!

Even though I’m sure that Alex will click the links to be sure that there really is no application before removing candidates when the application period closes :)

(when clicking the link, you get shown the actual existing page, not the "no page here" page)

hm

Yes , I do. Haven't copy/pasted yet

https://github.com/horazont/aioxmpp/pull/254/commits/f014831357cb7804c0ba6a5b45ebc65f62064bcf#diff-46a421af09863be52f28a8bb03d339d1R34 this is what I went for

(regarding the stream management discussion from earlier)

ralphm, can you replace my old blog (https://blogs.fsfe.org/vanitasvitae/category/xmpp/feed/) on the planet with my new blog (https://blog.jabberhead.tk/category/xmpp/feed) ?