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 :
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.
On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
>
>
>
> On Thu, Feb 6, 2014 at 12:28 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>>
>>
>>
>> On Wed, Feb 5, 2014 at 11:52 PM, Matthias Wessendorf
<matzew(a)apache.org>wrote:
>>
>>>
>>>
>>>
>>> On Wed, Feb 5, 2014 at 11:22 PM, Sebastien Blanc
<scm.blanc(a)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.
>>
>
> After reading your comment on the PR
>
https://github.com/aerogear/aerogear-js/pull/105#issuecomment-34324732 I
> 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