[aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter
Sebastien Blanc
scm.blanc at gmail.com
Wed Feb 12 11:47:34 EST 2014
On Wed, Feb 12, 2014 at 4:56 PM, Matthias Wessendorf <matzew at apache.org>wrote:
> What about using the encodeURIComponent() function ?
>
Ah yes :) that would be the best solution , and using URLDecoder on the
other (UPS server) side ?
>
>
> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:
>
>> i might have a couple thoughts, but i need to try some things out first
>>
>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>
>>
>>
>>
>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc at gmail.com>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://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id[
>>>
>>> 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 at apache.org>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 6, 2014 at 12:28 PM, 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.
>>>>>>
>>>>>
>>>>> 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 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
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> 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/20140212/dea009b1/attachment-0001.html
More information about the aerogear-dev
mailing list