Hello, On 3 Mar 2015, christian...@rechenwerk.net wrote:
> On 03.03.2015 16:16, Mickaël Rémond wrote: >> Hello, >> >> On 3 Mar 2015,christian...@rechenwerk.net wrote: >> >>> Then the client app hands this information over to its xmpp server >>> using the enable-iq stanza so the xmpp server can publish push >>> notifications when the client app is not reachable. >> What does it mean ? >> Suppose I am using MyApp on iPad and iPhone, with the same JID and >> resource (not using them at the same time). >> What does not being reachable mean ? > > You are right, the draft does not define any events when push > notifications should be sent. The old version didn't either but it > defined three cases to consider when such an event occurs: [1]. > I don't think there needs to be a list of unreachable clients, the > server knows when a client is not reachable: Well, in our implementation, we found that the server has no proper way to know where to push unless you have a registry of client. Here is a very common example: I would like to receive push on my mobile, even if my desktop client is connected. In that situation, the message will not use offline and may not use stream management (session may have expired). This is also the case if you have N devices. You may want to receive push on all of them, or only a few of them. The only way to hint the server about this, is to have > In my (currently broken) ejabberd implementation I chose to send > notifications in the following cases: > > - Stream management stores a stanza for a push-enabled user > - mod_offline stores a message for a push-enabled user > > This has quite complicated implications, because message delivery > rules (https://tools.ietf.org/html/rfc6121#section-8.5.4) are quite > complicated. First try to write them down: > > One or multiple push notifications are published if [...] > This is probably incomplete and can be written in a better form. The > question is, do we want to define these events in the XEP or leave it > up to the server when to send a push notification? I have to think > more about this. Yes. I agree about the routing for online users. This is not easy but can be sorted out by server developers. However, I think we miss a level of routing for "offline resources". At some point, I was toying with the idea of having queues to deliver offline messages to all devices when they reconnect. This was solve in some way with archiving as a way to provide catchup. However, the problem is back with push, as the client "stay offline" and you want to notify them with push. Relying on offline means you miss a rule: Delivering to "offline devices" means you need to know the offline devices. >> Yes, but the list need to be managed. Supposed I had two devices and >> now handed over one to someone else. I need to be able to get the >> list of devices that serve a reference for XMPP server to trigger >> push notifications sending. And as a user, I need to be able to >> manually clean that list in some rare but important cases. >> >> Does it make sense ? > I'm not sure if I understand this. If you registered at the app server > with resource A and enabled push at your XMPP server for A, you can > unregister and disable later for A on another device. But maybe I got > you wrong. What case are you thinking of? The resource is not enough as the resource is transient (In XMPP a resource only has a meaning during the session duration). It means you never know if it will be reused. Some clients like web client even use random resources to accomodate with multiple tabs, but still should represent a single device in term of push. They also can be shared between multiple devices at different moment. My point is that I think using the resource to identify a client app is not the correct artefact. I hope this help :) -- Mickaël Rémond http://www.process-one.net/
