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

[Daniel Bevenius]

+1 Sounds reasonable I think.


On 6 February 2014 12:28, Matthias Wessendorf <matzew at apache.org> wrote:

>
>
>
> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> 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....
>>
>
>
> 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.
>
>
> 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 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
>>
>
>
>
> --
> 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/6c86e742/attachment-0001.html