i had something, now i forgot what it was, need to go back and check
On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
still exploring
:-) any recent thoughts on 'encodeURIComponent()' ?
On Feb 13, 2014, at 3:39 PM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
>
>
> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
> i might have a couple thoughts, but i need to try some things out first
>
> Any update on that or does the solution proposed by Matzew (using
encodeURIComponent() ) could be enough ?
>
> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
>>
>>
>>
>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc <scm.blanc(a)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://update...
[
>>
>> 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(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
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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