On Di, 2015-03-03 at 21:55 +0100, Mickaël Rémond wrote: > 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
Where did the rest of that sentence go? :-) Thank you for pointing out this use case, in fact I didn't think about it. I think there are two events where a push-enabled offline user should be notified: - a push-enabled user had an open conversation with a friend then is busy with something else, the os suspends his app and server forgets about the session). After a while the friend wants to continue the conversation and sends a message to the user's full jid. (I know the standard recommends to initially send to the bare jid, but it's not illegal) - arriving message for a push-enabled user (bare jid) who's offline but before she went offline her session was the "most available" (as in [1]). I don't understand what you mean by registry of clients. When a client becomes unreachable it may not be able to tell the server about it. Example: The OS suspends the client app during a network outage. So I think the xmpp server has to decide whether to publish at an offline user's node by recognizing the two above events. This means we have to store the stanzas we notified the user about ourselves (damn, I was happy thinking this wouldn't be necessary). So if we detect one of the events, we have to store the message and prevent the server's routing mechanism to route it to another resource. This will certainly interfere with carbon messages, but I'll have to dig into that. > 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. Ok, the client may have another resource when it reconnects, but it will be still registered at the app server and thus will include the same node name into the enable-iq. So this will be the trigger for the server's push module to send the stored messages to the newly connected client. If for some reason the node name changes too often, the client can include a session-id in the enable-iq (like it was proposed in the old draft version) and the server can identify the client based on this (I hope this will not be necessary). Do you have more evil use cases? Christian [1] https://tools.ietf.org/html/rfc6121#section-8.5.4
