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

Matthias Wessendorf matzew at apache.org
Wed Feb 5 17:52:31 EST 2014


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 ?



> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140205/7b99f170/attachment-0001.html 


More information about the aerogear-dev mailing list