> coming online and going offline quite frequently, so they are not always receiving notifications
Well even if not hopping on/off, I don't want them to miss messages, and it's easy to do that with a browser-based client. > Have you looked at XEP-0184? I've glanced at Stream Mgmt and AMP. I'm pretty interested in solutions that are implemented, since my first priority is to ship an app! Pubsub is implemented, so if it got a reliable delivery feature, there's a decent chance it'd reach code. So I'm here to lobby for that :-) On Tue, Feb 2, 2010 at 12:22 PM, Liam <[email protected]> wrote: > I didn't top-post, I replied to my original note. I'm only subscribed to > digests. > > IQ notifications are spec'd to only work for present subscribers, which > doesn't help me. It'd be great if they would work for offline subscribers. > > As for getting involved, how else would I begin to do that but by asking > questions? Besides, I just suggested the outlines of a solution. (Which > might well be redundant with written XEPs.) > > > > On Tue, Feb 2, 2010 at 12:03 PM, Liam <[email protected]> wrote: > >> Seems to me that a reliability extension can be quite simple... It needs >> an ack mechanism, and a configurable retry/fail policy on the server. It's >> sorta surprising the core protocols lack this, IMO... >> >> >> >> On Fri, Jan 29, 2010 at 11:42 PM, Liam <[email protected]> wrote: >> >>> This blog post cogently positions XMPP against MQ systems >>> https://stpeter.im/index.php/2007/12/07/amqp-and-xmpp/ >>> >>> But now two years later, the pubsub spec makes no mention of reliable >>> delivery to offline subscribers, and even ejabberd doesn't implement AMP, >>> which could provide that. (Code's written, but integration appears to have >>> been deferred indefinitely.) >>> >>> It is astonishingly easy to miss messages with a browser-based client. >>> Um, have I chosen the wrong messaging technology for my app? >>> >>> >> >
