On Di, 2015-03-10 at 01:27 -0700, Lance Stout wrote: > The defined workflow is that when the XMPP server detects something > interesting > happened, then it has a set of JID+node endpoints that can be informed of that > interesting event via pubsub publishes. We could let the server have the > option > to pick which of those JID+node combos it will publish to, but there is not a > defined way to choose any particular subset. However, there are options > available to > pick from, for example: > > - Was the interesting event associated with a particular resource that also > had > enabled push services? Send the publish to only those services. > - Are there push services for a user which have not been enabled by any of > the > user's current online sessions? Send the publish only to those services. > - Publish to all enabled services regardless of if the user has any online > resources. > > I expect that the XEP will expand to cover this topic once we have some more > implementation experience on what works well in practice. >
As there's currently no specification on what are interesting push events, it's completely up to the implementer. My implementation currently defines events as: a message / presence subscription was stored by stream management's resumption feature This means if a client enables push and then goes offline it'll never receive notifications (unless it goes back online). The server will send notifications only if the client closed the tcp connection without sending the closing stream tag or when a dead tcp connection is detected. Is this a valid interpretation? We should define what going offline means for push (at least say it's up to server implementations).
