On Tue, Jan 21, 2014 at 10:44 PM, Lance Stout <[email protected]> wrote: > So I install Otalk on my phone, and establish a connection to my own server, > lance.im. > The Otalk client detects that lance.im supports the push extension via > disco/caps. > The Otalk client then registers the 'push.otalk.im' endpoint (which the Otalk > client > knows about because it's hardcoded) as a recipient for push notifications for > [email protected] on lance.im. Included in that registration MAY be some ID value > that the Otalk client provides, which is completely opaque and only intended > for > use by 'push.otalk.im' as the registered endpoint. (Eg, the Otalk client app > could > request an ID value from its backend server that associates '[email protected]' > with a > device id/token before starting the registration process at lance.im.)
Hi Lance, that's what I was talking about: that "opaque ID" is the device token which must reach the push notification component, otherwise it wouldn't know how to send the push notification request to the proprietary server (e.g. GCM). If I got it right, it's in the "id" attribute of the <register/> element so, I didn't notice it at first. And, if I got this right too, this sentence should be expanded: "MAY specify an opaque id attribute that the receiving service MAY use to target that specific device when using stream management" adding something like "or when sending a push notification to the proprietary service" or something like that. Can you please explain this: "When set to "client", the recipient will receive a notification only when there are no online connections that have specified the same recipient." Also you say in your e-mail "it's up to the app's backend service to forward that notification over its preferred proprietary push service to the installed app on some device." Are you saying that the client has to connect to the push notification proprietary service instead of the server doing it? -- Daniele
