[Standards] Call for Experience: XEP-0198: Stream Management

Andrew Nenakhov andrew.nenakhov at redsolution.com
Thu Feb 20 19:57:48 UTC 2020


чт, 20 февр. 2020 г. в 16:05, JC Brand <lists at opkode.com>:
> > Through the message archive and with our device sync protocol.
> What if you had only one device and presence stanzas were sent during
> the disconnection?
>
> With your way of doing things, you'd have to query MAM every time you
> load a web-page that contains an XMPP chat. Seems excessive.
>
> I know your web chat client isn't meant to be embedded in websites where
> people navigate around, but that is a common use-case.

Well. This requires an explanation of how we see things. What is, exactly,
a use-case for stream management? It helps in situations, when a connection
is lost frequently, yet, briefly. Where can this occur? On a desktop, with
a stable connection, it is hardly a problem: connections are stable there,
and if something happens, one full reconnect every 30 minutes (much more
rare in practice) is something any client can tolerate. This leaves us with
mobile devices and browsers.

Mobile clients are, currently, a valid use-case for stream management.
Mobile devices often hop from wifi to cellular connection and back, are
brought to places with bad signal coverage, so they can benefit from SM.
However, only on one platform - Android. iOS devices would not benefit from
stream management at all - they can't maintain connection in the
background, and rely on APNS to receive notifications about a necessity to
connect to server. Android seems to be on the same trajectory: persistent
processes have more and more difficulties living in the background with
each release. Some manufacturers even make it even worse, see
https://dontkillmyapp.com/

I believe that writing is on the wall for mobile devices, and in the long
term we are destined to be forced to use push notifications in the future.
So, only browsers remain.

If a browser is emulating a full-on desktop app, like Xabber for Web, it
does not really need SM, just as desktop apps don't need it. If it behaves
like converse.js, reloading on every page... well... it's a reasonable
place to use SM. I personally can't really imagine a scenario where a user
might want to have a real XMPP experience that way, complete with roster
and presences, but I trust you that you know your users better.

(I can very well imagine a scenario where an XMPP is used on a website to
provide an olark/purechat/livechat chat widget to talk to site owners, and
in fact we're making a rather nice chat widget ourselves
<https://demo.webchat.dev.xabber.com>, powered by our awesome group chat
protocol, we break it from time to time and do not always answer to
incoming requests, so I don't promise stability just yet)

So. Back to SM. Long term, we're dealing with 2 types of clients: one that
have a stable connection, and ones that connect to servers infrequently and
do not maintain a connection at all. The latter type of clients relies on
message archive and our device sync protocol, and I can't call fetching
messages from an archive as some excess, and practice shows it works quite
well. (btw, we're disabling offline messages)

What other problems we have with reconnection? Roster and presences. Roster
is mostly not a problem thanks to roster versioning. Presences. It's a big
problem I'm still on the fence for this one. Receiving all presence
information on each reconnect is not the ideal solution. I'm thinking of
using a presence versioning, akin to roster versioning, or maybe to
eschewing presences at all. The idea of 'always on' messaging has some
merit to it with always connected modern mobile devices, however,
personally, I am not ready to give up on green light bulbs on contacts just
yet.



-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200221/f4805d94/attachment.html>


More information about the Standards mailing list