[Standards] Call for Experience: XEP-0198: Stream Management
andrew.nenakhov at redsolution.com
Wed Feb 26 11:25:16 UTC 2020
пт, 21 февр. 2020 г. в 14:33, JC Brand <lists at opkode.com>:
> I have worked on deployments where Converse.js is integrated together with roster and presences and/or MUC presences and where pages are regularly reloaded (i.e. not a single-page app).
Btw, I assume you use a strophe.js library. Personally, I didn't dive
into details, but my web developers who work with web version of
Xabber, which also uses this library currenlty, complained to me about
SM implementation there. It was something about it counting stanzas
differently than ejabberd does. It was over a year ago so I am not
very sharp on details, but I can ask them for a clarification, email
me directly pls if you want it.
> Is there anything specific about SM that you don't like?
> It's more lightweight than having to do MAM requests for all open chats as well as making a new roster request every time your connection drops and it also solves the problem of presences being dropped.
Things I don't like in SM is that it was often marketed as a way to
reliably control the message delivery in the past. Thankfully, now
it's commonly accepted that it's not its goal. But currenlty I find
this method of maintaining connection not viable for our most
problematic platform, iOS. Thus, versioned methods of resuming chat
state were born, and they're as applicable on desktops, as they are in
web / iOS / Android devices. In worst-case scenarios, these methods
result in equal amount of traffic as with SM on reconnection, in best
cases they result in smaller amounts of traffic.
Mind you, I'm not advocating to drop SM, it's just our position that
it is redundant for us.
CEO, redsolution, OÜ
More information about the Standards