Hello, On 10 Mar 2015, [email protected] wrote:
>> So I think using the node name as a device identifier (or more >> precicely: an identifier for entities that want to receive the same >> push notifications and are thus registered for the same node) is >> sufficient for the xmpp server. > > Yes, that is the correct interpretation. Imagine for example that > Apple's push service was actually implemented as an XMPP Push > Service. The 'device ID' given to your iOS app would be the node. > > What a node actually represents is 100% completely arbitrary and > decided by the App Server. The App Server you create for your new app > could treat node == device ID so that it can target specific devices, > or you might want to just always notify all of a user's devices (or > none!) and thus node == user. All of which means that your XMPP server > has no internal knowledge of phones or devices, only of > applications/services. The problem with that approach is the the XMPP server needs to know if a device is online or not. It is the responsability of the XMPP to know which node to notify. To send a push notification to a device, it need a baseline and to compare with list of online devices. >> When a client sends an enable stanza the server updates an existing >> record for the client's full jid with the stanza's new 'node' >> value. That's actually already described in the XEP. > > I may need to add additional clarifying language to the XEP > then. Enabling and disabling as defined is for the bare JID account > level. However, servers could keep track of which services a > particular resource connection enabled and use that information to do > more intelligent notifications. We do not have a unique mapping between app and resource. For example, some client decide to use the same resource on all devices to be able to kick the existing session. Then, mapping the push to a resource is not enough, thus my device registry need. > 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. It seems there is a case that is not handled is: publish to all devices on which the client is offline. > I expect that the XEP will expand to cover this topic once we have > some more implementation experience on what works well in practice. > > Of course, what defines interesting (and the levels and kinds of > interesting) is left to the server implementation and to future XEPs, > but there are a lot more potential things than just offline messages. Well, I have made a a custom implementation of such service already and I know that I need to keep a list of registered devices. When the session opens and it send the push configuration packet, it give again its device id. That allow the server to tell that this specific device is online (and put it offline on disconnect). The most basic and useful use case is to have that baseline of offline / online devices to be able to send push to all offline devices. > Then your App Server needs to provide a way to disable notifications > to your phone, which is already the case today for mobile apps. The > topic of push is hard to talk about without assuming everything is > directed to mobile devices, but the point is that XMPP servers really > shouldn't need to know what a phone even is. Consider XMPP Push > Services whose associated App Server is nothing more than a daily > 'things you missed' email summary generator — a case with no mobile > app, no mobile device, and no particular associated resource. Yes, I agree to cover those cases, but we need to have the case most of the developer expect to be covered answered as well. I think we can make that device registry (ability to pass a unique device ID on push enable in XMPP) optional. We will probably cover the use case that are not mobile in the same good way. But my feeling is that we need that registry if we want to cover the mobile case. -- Mickaël Rémond http://www.process-one.net/
