[Standards] Call for Experience: XEP-0198: Stream Management
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
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...
More information about the Standards