чт, 19 нояб. 2020 г. в 17:45, Florian Zeitz <flo...@babelmonkeys.de>: > > Am 19.11.20 um 11:11 schrieb Andrew Nenakhov: > > Because you are happily oblivious to problems of clients on some > > platforms that have a very tiny window of operation before they have > > to break connection. > > > > May I suggest that you explicitly spell out your concern instead of > being hostile? > > As far as I can tell for sending/receiving stickers this XEP does not > actually use PubSub but SFS/plain file downloads. There is also no need > to subscribe to the PubSub node, so your comparison with presence seems > out of place. The only interaction with PubSub is upon creating and > importing a sticker pack, which amount to a single IQ set/get > request/response pair each. > > I do BTW admit to personally being relatively oblivious to mobile > concerns, but not happily so.
In mobile XMPP, especially on iOS, stream is an extremely valuable resource, because you have so little time to do so many tasks. Things are bad enough with presence flood, which chokes the stream every time on each new connect, so *anything* that excessively goes into the stream but actual messages is an obstacle. So of course, we use HTTP for hosting sticker packs and stickers themselves, and any client on any OS can *easily* import any image by their URIs. This way clients do not need to use pubsub or anything, just use the links, super easy. Also, this model makes updating the pack more easy. Beyond that, we've actually come to understanding that single-connect model is fundamentally broken and stands in the way of good, and have rather successfully implemented multiple streams into clients. So loading dreaded presences and new messages come in the main stream, where you post presence, and loading an archive for specific conversations happens in another. Fetching list of group chat members happens in another, etc. On iOS (and on Android too, actually) it is almost always faster to open a new stream and fetch only the required data, than to load everything on the only stream. This makes interfaces far more responsive, and, among other things, makes stream management unnecessary. In our further plans we plan to solve the problem of presence flood, by replacing current presences with one 'super presence' for an account, stoping presence propagation to contacts, and merging this super presence with roster versioning. This way, on each new reconnect the client will have to do the following: - catch up with changes in the list of recent conversations using quick sync protocol - fetch differences in roster version since last reconnect - start receiving messages. It won't be flooded with presences, or pubsub updates. So far, we have quick sync protocol done & working, it syncs everything in a couple of seconds, complete with unread messages and read marker info. But presence and pep traffic still remains a problem. All of this is rather far stray from 'regular xmpp', but we just don't see how we can make a good communication product using 'xmpp compliance suites 2021' on all target platforms. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
