Re: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter

still exploring

On Feb 13, 2014, at 3:39 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > i might have a couple thoughts, but i need to try some things out first > Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? > > On Feb 12, 2014, at 3:53 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > > On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> Ok, >> I've been doing some tests by using the PushEndpoint as device token. >> For registration it works but I just faced an issue by trying to unregister >> because the URL for the DELETE looks like : >> >> >> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://update... >> >> And the REST endpoint get a bit crazy by the extra "/" present in the >> endpoint URL. Therefore, I think we must just use the last URL fragment as >> deviceToken. >> > > Ok answering to myself ;) That won't work neither since if we do that UPS > won't have the compllete push endpoint URL. > So how do we deal with that ? > >> >> >> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf < >>>> matzew(a)apache.org&gt; wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf < >>>>> matzew(a)apache.org&gt; wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc < >>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Hi, >>>>>>> While playing today with my Firefox Device and its native Simple >>>>>>> Push support I noticed some differences between our implementation and the >>>>>>> native Push regarding the success callback after a register : >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> //Native FFOS Push >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = broadcastRequest.result; // only contains the pushURL >>>>>>> } >>>>>>> >>>>>>> >>>>>>> //Aerogear Push Adapter >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = broadcastRequest.result.pushEndpoint; >>>>>>> channelID = broadcastRequest.result.channelID; >>>>>>> version = broadcastRequest.result.version; >>>>>>> status = broadcastRequest.result.status >>>>>>> } >>>>>>> >>>>>>> So, the AeroGear Push exposes much more in the callback that it >>>>>>> should suppose to do : just exposing the pushEndpoint. >>>>>>> >>>>>>> The reason we do that I suppose, but Luke or Kris could confirm >>>>>>> that, is that we thought respecting the SPS protocol, which indeed returns >>>>>>> a whole object containing all the info. It is just that the Native Push >>>>>>> Client API filter that out in the callback response. >>>>>>> >>>>>> >>>>>> >>>>>> Did they change that recently? Or was theirs always like it is now ? >>>>>> >>>>>> >>>>>> >>>>>>> After discussing that on the #push channel with the Mozilla >>>>>>> people they confirmed me that we should only expoe the pushEndpoint. >>>>>>> >>>>>> >>>>>> >>>>>> yep, I agree on changing our JS polyfil >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> If we keep it as is, this can be problematic when we want to use >>>>>>> the same code both for native and with the adapter when, for instance, >>>>>>> registering to the UPS : >>>>>>> >>>>>>> broadcastRequest = navigator.push.register(); >>>>>>> broadcastRequest.onsuccess = function (event) { >>>>>>> broadcastEndpoint = event.target.result; >>>>>>> var broadCastSettings = { >>>>>>> metadata: { >>>>>>> deviceToken: broadcastEndpoint.channelID, >>>>>>> simplePushEndpoint: broadcastEndpoint.pushEndpoint >>>>>>> } >>>>>>> } >>>>>>> UPClient.registerWithPushServer(broadCastSettings); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> This won't work with the native push since "broadcastEndpoint.channelID" >>>>>>> will be undefined. >>>>>>> >>>>>> >>>>>> sweet :-) >>>>>> >>>>>> >>>>>>> >>>>>>> So I propose that we change the behaviour, to return only the >>>>>>> pushEndpoint in the callback, even if that means a bit of String >>>>>>> manipulation when we want to perform the registration to the UPS : >>>>>>> >>>>>>> var broadCastSettings = { >>>>>>> metadata: { >>>>>>> deviceToken: broadcastEndpoint.substr(broadcastEndpoint.lastIndexOf('/') + 1), >>>>>>> simplePushEndpoint: broadcastEndpoint >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>> well, that's not really good for security reasons, since their >>>>>> looooong 'substring' was done for that. Also that's just redundant. >>>>>> >>>>>> The I guess, the deviceToken (channelID registration) might be a bit >>>>>> bogus, for SimplePush. Let me think about it.... >>>>>> >>>>> >>>>> >>>>> Right now we use the channelID as the deviceToken, but we should not >>>>> really 'leak' the channelID (see [1]), so I guess the here proposed change >>>>> makes sense. Don't recall exactly why we did it in the past, but yeah - >>>>> let's change it. >>>>> >>>>> >>>>> Thinking about the consequence: I think we should use store the value >>>>> of the returned 'pushEndpoint' string as our device-token. At the end the >>>>> device-token is really the thing that identifies a device w/in the target >>>>> network. Apple/Google uses a unique string, and if Mozilla uses a URL, >>>>> that's totally fine. >>>>> >>>>> Reading the protocol definitions (see [1]) for the 'endpoint' I think >>>>> it is fair to use that (unique) URL string as the device-token; And we >>>>> could use this token value as well for the unregister calls, instead of the >>>>> channelIDs. >>>>> >>>> >>>> After reading your comment on the PR >>>> https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732I understand that you just want to use the deviceToken and not pass the >>>> simplePushEndpoint to UPS anymore, is that right ? >>>> >>> >>> >>> yep >>> >>> >>> >>> >>> >>> >>> >>> >>>> >>>>> >>>>> Any thoughts ? >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#Definitions >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> That said, we still have no clue how to proper clean-up 'out dated' >>>>>> channels, since the SimplePush Server/Protocol is silent on that (unlike >>>>>> APNs / GCM). but that's really a different thread (yep, we have a future >>>>>> JIRA for that) >>>>>> >>>>>> >>>>>> -M >>>>>> >>>>>> >>>>>> >>>>>>> wdyt ? >>>>>>> >>>>>>> Seb >>>>>>> >>>>>>> >>>>>>> ps : our SPS Server implementation stays correct and returns what >>>>>>> should be returned, it's really just the client part and how we expose the >>>>>>> result >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev