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

JC Brand lists at opkode.com
Fri Feb 21 09:32:42 UTC 2020

On 20.02.20 20:57, Andrew Nenakhov wrote:
> чт, 20 февр. 2020 г. в 16:05, JC Brand <lists at opkode.com 
> <mailto: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 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).

Other people have integrated it into Diaspora and other FOSS social 
networking sites, many which aren't single-page apps and therefore cause 
page reloads when people navigate around.

The site I'm working on currently will eventually want DMs and the 
ability to request a DM (aka presence) and it's also not a full SPA.

> (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)

As Daniel and Guus have pointed out, you're not dealing with only these 
two types of clients. You can also have laptops connected to spotty wifi.

> 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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200221/6038ea9c/attachment-0001.html>

More information about the Standards mailing list