Hello, On 4 Mar 2015, christian...@rechenwerk.net wrote:
> 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? :-) Oups, bad keyboard shortcut. Sorry about that. I was saying that the way to hint the server is tell him what are the expected online client so that he can tell which ones are offline. > 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. Well, you do not have to notify the server if the server knows that you have two mobile devices for example a phone and a tablet. When you send the stanza to enable push after login, it will know you are online. When the session close, it will know that device is offline. By comparing the list of devices requiring pushes with the list of online devices, the server knows to which it needs to send push. No need to remind him on connection lost. > 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. I think we do not need to do that: We can simply route to online users + push to offline devices (By comparing to the list of expected online devices). > 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). I think the client should have a client reference in the enable IQ. It is not a session id per say but a unique client id. If that client is not online, then it triggers a push. Unless, you are expecting to use the node as that unique ID for that client. But in all cases, the server need to have a way to know "What are the list of devices that user should have online ?" And I think the user should be able to retrieve it to delete devices he does not use anymore. > Do you have more evil use cases? I will think about it more :) Thanks :) -- Mickaël Rémond http://www.process-one.net/
