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. Regards Spencer On Mon, Oct 28, 2013 at 6:05 PM, Dave Cridland <[email protected]> wrote: > On Mon, Oct 28, 2013 at 5:54 PM, Peter Waher <[email protected]>wrote: > >> > How do we define "important"? There's the challenge. :-) >> >> True. But not only "how", but also "where" it is defined. The received >> can define what it wants, the xmpp server can define what to forward under >> certain conditions, and the sender can define the priority of a message. >> >> Many network protocols have solved this by letting the sender determine a >> priority or QoS level for each message. The sender normally knows if >> something is "important" (for instance an alarm, or a call or control >> command) or "normal" (informational message) or "less important" (recurrent >> status update), for instance, and so no complex logic for this is required. >> >> An objection could be made that an application could then choose to send >> all messages as "important" messages, overriding any throttling logic. But >> in practice, this would be counterproductive since users would quickly find >> out what service/device/address works badly and stop using it or >> unfriending misbehaving contacts. >> >> The above solution could then hypothetically be complemented by a simple >> subscription mechanism on the client, or an automatic rule on the xmpp >> server determining what messages to forward and when, and perhaps also with >> bandwidth limits on different types of messages, and if messages not being >> forwarded should be treated as offline messages or thrown away (based on >> message priority). >> > > I think this is XEP-0334, Messaging Processing Hints. Or ought to be, at > any rate. >
