Hi, now Push is getting some traction. Multiple (even larger) server operators have enabled the Prosody module. Conversations has client side support for it. ChatSecure iOS with Push support is going to be released soon. The ejabberd module is in planing stages as well. It is very important that client and server devs are on the same page and have a common ground to work with. IMHO this Push XEP is clearly missing some business rules. I started writing up some rules a few month ago and I'm still convinced that those are the 'correct' conditions. At least for an IM context. I would really love to formalize them in the XEP since feedback has generally be positive.
2016-02-16 13:32 GMT+01:00 Daniel Gultsch <dan...@gultsch.de>: > > 1) A server - over time - collects the various delivery targets which are > a combination of jid and node attribute + x contained in the enable request. > 2) A client resends those on every connect (because it can not know > whether the server already knows about this particular delivery target. > 3) As a consequence of (2) the server knows the delivery target for a > particular session > 4) There are three different 'push scenarios' (Situations in which the > server should initiate a push) > a) In a XEP-0198 stream management session with a closed TCP connection > the server should notify the corresponding delivery target on every new > stanza that would have been delivery if the TCP stream was alive (meaning > all stanzas but honouring CSI if enabled.) > b) If a message is being archived into MAM (honouring the MAM archiving > rules) *every* delivery targets should be notified unless that delivery > target was already notified by rule (a) > c) copies rule (b) for offline messages meaning all delivery targets > should be notified when a new offline message arrives. > > > (c) and (b) can be combined into one push scenario depending on the server > implementation (when MAM and offline are fed by the same data source) > > for (a) it is no required to keep the session open for much longer than > regular. (ejabberd currently does this so i'm saying this here) > I have a small modification/footnote to (a): The server should keep the smacks session open for $normal-timeout after sending the first push. As apposed to an extremely long timeout like 12h our 'infinite' this puts much less stress on the server. But also gives an idle client a fair chance to still resume a session. I would also like to incude these client side rules: (For IM) If you have the ability to resume a smacks session on your platform. (Either because the OS doesn't kill or because your library allows you to serialize to disk) you should just close the socket when going to background instead of closing the stream. This way you will always be in 'push scenario' (a). And you avoid having to create a whole new session on every connect. cheers Daniel
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
