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

Thu Jul 24 09:20:31 EDT 2014

On Thu, Jul 24, 2014 at 3:17 PM, Lucas Holmquist <lholmqui at redhat.com>
wrote:

>
> On Jul 24, 2014, at 9:14 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> On Thu, Jul 24, 2014 at 2:41 PM, Lucas Holmquist <lholmqui at redhat.com>
> wrote:
>
>>
>> On Jul 24, 2014, at 6:19 AM, Tadeas Kriz <tkriz at redhat.com> wrote:
>>
>>
>> —
>> Tadeas Kriz
>>
>>  On 23 Jul 2014, at 09:56 pm, Lucas Holmquist <lholmqui at redhat.com>
>> wrote:
>>
>>
>> so there is this issue,  , about not being able to delete a simplePush
>> installation.
>>
>> using the UPS js client,  i registered the “deviceToken” with the push
>> server, but when trying to use CURL or even the JS lib,  i was getting a
>> 404, and i noticed that it would never actually hit the server( i was in
>> debug mode in IntelliJ )
>>
>> this was a demo that i had working back in april
>> https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17
>>
>> i noticed that when i registered the deviceToken, i was doing a
>> encodeURIComponent before sending it to the UPS.
>>
>> i modified the UPS JS client to do it this way, and then when i tried to
>> do the remove,  i actually hit the breakpoints i set.  but the server could
>> not find the installation doing
>>
>> Installation installation =
>>
>> clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(),
>> token);
>>
>>
>> I changed the JS client to only do 1 encode instead of 2 but it still
>> couldn’t find the installation.
>>
>> I’m not really familiar with JPA and all that,  so i don’t know how the
>> query stuff works in this case
>>
>>
>> But i do think we should be encoding the deviceToken( which is the
>> pushEndpointURL ) when registering with the UPS, or else i don’t think we
>> can ever get access to that endpoint
>>
>>
>> I’d rather not require this. I mean, if there is no other way, then yes,
>> let’s encode, but I can’t see the reason why would that be a problem.
>> Basically, when you put it into the JSON when registering, it’s just a
>> string and string can have any possible character, no matter what. Then the
>> request. When it’s encoded one time, so it can be put into the URL, it
>> should be enough for the server to use it and to search an installation in
>> the database.
>>
>>
>> The problem is that you are not able to access the endpoint.
>>
>> /shortenedURLForBrevity/
>> http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf
>>
>> basically, that is the endpoint you need to send a DELETE to.  which
>> isn’t possible
>>
>
>
> I guess on Android that's never a problem because the endpoint there looks
> like:
> /shortenedURLForBrevity/+MY_GCM_TOKEN
>
>
> right, same for iOS,  it’s just SimplePush that has the issue,  since the
> token is a URL
>

I also wonder if our Hibernate layer has issues w/ and URL as the token :)
Hadn't had the time to check that yet

-M

>
>
>
> Passos, can you confirm ?
>
> -M
>
>
>
>>
>> We could also encode on the server side before storing,  and the
>> libs/CURL would need to encode for a DELETE?
>>
>>
>> Is is possible that there are some Hibernate’s restrictions for the
>> “deviceToken” field?
>>
>>
>> On Jul 14, 2014, at 9:52 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>
>>
>> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>> Hey Luke,
>>
>> I created this JIRA:
>> https://issues.jboss.org/browse/AGPUSH-802
>>
>> As I plan working on AGPUSH-532 next week, to make sure we have the
>> 'right' model in place for 1.0.0. I think once the server bits are merged,
>> we should address AGPUSH-802
>>
>>
>> kk
>>
>>
>> -Matthias
>>
>>
>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist <lholmqui at redhat.com>
>> wrote:
>>
>>> so after testing this thing out with encodeURIComponent,  the delete
>>> does work,  however,  we need to "double up" the encode.
>>>
>>> this works:
>>>
>>> https://gist.github.com/lholmquist/10393357
>>>
>>>
>>> this doesn't:
>>>
>>> https://gist.github.com/lholmquist/10393450
>>>
>>>
>>>
>>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>
>>>
>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>> Ok,
>>>
>>> So as token, we use the endpointURL, and on client we perform  the
>>> encodeURIComponent() function ?
>>>
>>>
>>> i think so( as suggested 2 months ago  :) )   i just need to see how
>>> this will affect how we store stuff in LS.
>>>
>>>
>>>
>>>
>>> -Matthias
>>>
>>> On Monday, April 7, 2014, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>
>>>> so i went back to look at what i had,
>>>>
>>>>
>>>> i don't think we need to get to complicated here,
>>>>
>>>> reading the spec stuff, and this example
>>>>
>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code
>>>>
>>>> they show sending the pushEndpoint to the "App server",  so i think we
>>>> could just use and keep it simple
>>>>
>>>> it is also recommended that the channelID is never exposed to the
>>>> application.
>>>>
>>>>
>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist <lholmqui at redhat.com>
>>>> wrote:
>>>>
>>>> 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 at apache.org>
>>>> wrote:
>>>>
>>>>
>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist <lholmqui at redhat.com>
>>>> wrote:
>>>>
>>>> still exploring
>>>>
>>>>
>>>> :-) any recent thoughts on 'encodeURIComponent()' ?
>>>>
>>>>
>>>>
>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> 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 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
>>>>
>>>>
>>>
>>> --
>>> Sent from Gmail Mobile
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> 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
>

-- 
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/20140724/01470a45/attachment-0001.html 