I think your under estimating the amount of messages somebody receives in an active chat, especially when some people tend to split their messages up like so:
Message 1: Hi Message 2: How are you Message 3: ? Message 4: :) Moreover if your mobile app has a Desktop counterpart you might end up being a participant in one or more group chats, like you said could end up generating a lot of traffic. Also (iOS specific again, sorry) your not allowed to use the background socket for "messages" anyway, thats what push notifications are for. Also the user is not informed in any way that the app has been killed so they wouldn't bother to relaunch it, thus not resuming the stream until the next time they want to send a message. Regards Spencer On Mon, Oct 28, 2013 at 9:46 PM, Dave Cridland <d...@cridland.net> wrote: > On Mon, Oct 28, 2013 at 7:57 PM, Spencer MacDonald < > spencer.macdonald.ot...@gmail.com> wrote: > >> I have used a custom implementation that just had the following commands: >> >> - Enable (enable the buffer) >> - Flush (flush the buffer) >> - Disable (disable the buffer, which also flushes it) >> >> It worked great, but I wasn't using any time sensitive XEPs like Jingle >> that you would want to let through. >> >> The major issue on iOS is if the device "wakes up" more than 15 times in >> 5 mins your app would get killed, so letting through "important" messages >> still wouldn't be a good idea. >> >> > Right; the google:queue implementation I once wrote, in a past life, > buffered up only presence. IQ, and messages, came through - but it was > clever enough to figure out that local PEP at least was bufferable. > > I suspect though that most people would handle less than 3 messages a > minute on mobile for at least most of the time. I only get that kind of > level on desktop if I'm in a MUC or two. > > Even if the client was killed, the combination of mobile push and XEP-0198 > should make that fairly painless, too. > > Dave. >
