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

[Sébastien Blanc]

Envoyé de mon iPhone

Le Feb 5, 2014 à 23:52, Matthias Wessendorf <matzew at apache.org> a écrit :

> 
> 
> 
> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc <scm.blanc at gmail.com> 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 ?
Hard to check the history but I think it has always been like that.
> 
>  
> 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....
> 
> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140206/4c23e74a/attachment.html