I think I should give you a real example where ISR really matters: Under iOS you can not run your app in the background and keep it permanently connected. And push doesn't always wake up your app in the background (there are *some* circumstances which allow this but much more exceptions).
So: If you get a message you will receive a push notification saying that there is a message waiting for you (not containing the content of the message for obvious privacy reasons). If you tap on this notification your app will open, connect to the xmpp server, receive the message (either via MAM or by resuming an already existent smacks session) and display it. +1s RTTs on slow mobile links are not an exception. So every time a user wants to read a new message he has to wait a couple of seconds till the app is ready to actually display what he wants to know. Even if the UI is designed well and shows a waiting screen with a spinner on it or something like this the user *still* has to wait for 5 seconds or even longer. Everything that reduces the needed RTTs makes this situation better and I think XEP-0397 should be more than welcome if it solves (or at least attenuates) the described issue . Only my two cent. Am Montag, 22. Januar 2018, 17:13:00 CET schrieb Evgeny Khramtsov: > Mon, 22 Jan 2018 13:42:59 +0000 > > Dave Cridland <[email protected]> wrote: > > I don't think RTTs should block UI either, but startup RTTs mean we > > cannot send or receive messages for several RTTs, and that's a very > > real problem over slower networks. > > What problem? If you're on slow network, expect everything to be > slow, because, well, the network is slow. > > > From a more cynical standpoint, it also addresses a commonly held > > belief about XMPP (startup is really slow and it's really chatty!) > > without causing harm. > > I don't see this as a "commonly held belief". If you know how Web works, > you would never assume XMPP is slow. I don't remember anyone > complaining in my bugtracker about slow RTT. > > To put it simply: I agree there can be use cases when you absolutely > need to work in a slow network (sending stanzas to the Moon and back, > as an example), and maybe there are indeed some problems with RTTs. But > I see this as a very narrow use case. So I would agree that the XEP will > be used by *some* software, and I'm fine with that. What bothers me is > that this may become a trend, seeing the XEP as a successor to the > "standard" approach, and even be put into "compliance suite". > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
