чт, 20 февр. 2020 г. в 16:05, JC Brand <li...@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
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
