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

Mon Jul 28 11:23:35 EDT 2014

OK, fair point.

Once I am done w/ documentation, I will get back to this - unless some else
beats me to it :)

On Mon, Jul 28, 2014 at 4:56 PM, Luke Holmquist <lholmqui at redhat.com> wrote:

> I would rather not have to generate some id and then store that locally.
>
> Simple push is not the only thing the uses the UPS client.
>
> Sent from my iPhone
>
> > On Jul 28, 2014, at 3:36 AM, Karel Piwko <kpiwko@ .com> wrote:
> >
> > Yes, that was it. And you're right, it indeed makes better sense to
> > generate UUID by client, not by server.
> >
> > Karel
> >
> >
> >
> > On Fri, Jul 25, 2014 at 3:19 PM, Matthias Wessendorf
> > <matzew at apache.org> wrote:
> >>
> >>
> >>
> >> On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko <kpiwko at redhat.com>
> >> wrote:
> >>> On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf
> >>> <matzew at apache.org> wrote:
> >>>>
> >>>>> UPS can translate {deviceToken} to EndpointURL. We just need a way
> >>>>> how
> >>>>> to generate unique {deviceToken} on client.
> >>>>
> >>>> that would be our own layer on-top, which is a no-go
> >>>
> >>> why? it would be there anyway. Imagine that your UPS is running on
> >>> exposed URL which is a gateway to your internal network. SP URL is
> >>> valid only in that internal network, not visible from outside world
> >>> at
> >>> all.
> >>>
> >>> So, using UPS is the only way to send the message to that URL.
> >>
> >> Hrm... let's see if I am following you. Let's try:
> >>
> >> If the UPS has a mapping between "magic_UUID" and endpointURL, that
> >> means the client layer (e.g. UPS.js) has to store this UUID
> >> somewhere, for unregistration.
> >>
> >> Instead of having the UPS generating the UUID, it could be generated
> >> by the UPS.js, and its JS callback would/could return it (so that the
> >> JS app has it handy for later unregister).
> >>
> >> That would mean the JS client would sending down the same JSON as
> >> before, right ?
> >>
> >> deviceToken: client_side_generated_UUID,
> >> pushEndpoint: someURL
> >>
> >>
> >> Did I get it ?
> >>
> >>
> >>
> >>>
> >>>>
> >>>>
> >>>>> Would UUID work?
> >>>>> EndpointURL can become part of JSON [1].
> >>>>
> >>>> it was there as "simplePushEndpoint", but for stated reasons it's
> >>> now
> >>>> the deviceToken that has the URL value
> >>>>
> >>>>
> >>>>>
> >>>>> Such change would mean that clients can't use SP server directly
> >>> but
> >>>>> have to go through UPS. This makes more sense then current setup
> >>> to
> >>>>> me.
> >>>>
> >>>> not really
> >>>
> >>> See reason stated above.
> >>>>
> >>>>>
> >>>>> Karel
> >>>>>
> >>>>> [1]
> >>>
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74
> >>>>>
> >>>>> On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf
> >>>>> <matzew at apache.org> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz <tkriz at redhat.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> —
> >>>>>>> Tadeas Kriz
> >>>>>>>
> >>>>>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius
> >>>>>>> <daniel.bevenius at gmail.com> wrote:
> >>>>>>>
> >>>>>>>>> 5. don’t use the url as a deviceToken (might not comply
> >>> with
> >>>>>>>> Mozzila’s SimplePush specs)
> >>>>>>>> The deviceToken is an UPS concept and there is nothing in the
> >>>>>>>> SimplePush spec which is violated in this case.
> >>>>>>> I thought that deviceTokens were changed from a generated
> >>> value to
> >>>>>>> the URL just to comply with Mozzila’s SimplePush specs.
> >>>>>>
> >>>>>> Nope
> >>>>>>
> >>>>>>> Matzew, why was the generated token removed then?
> >>>>>>
> >>>>>> It was the channelID before - but that should not be exposed.
> >>>>>> In GCM devices are identified via registrationID
> >>>>>> In APNs devices are identified va deviceToken
> >>>>>> (both are somewhat the same - but different names)
> >>>>>>
> >>>>>> In SimplePush devices are identifeid v/ the URL of the
> >>> pushEndpoint
> >>>>>> (a backend uses that endpoint to notify _THAT_ client,
> >>> regardless
> >>>>> of
> >>>>>> how many channels it has subscribed)
> >>>>>>
> >>>>>> So, that lead us to make the change (see history of this threa)
> >>>>>>
> >>>>>> -M
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>> I'm not sure about what the best option is for UPS thought.
> >>>>> Would a
> >>>>>>>> regex in for the @Path annotation work perhaps, something
> >>> like:
> >>>>>>>>
> >>>>>>>> @DELETE
> >>>>>>>> @Path("{token, .+}")
> >>>>>>>> public Response unregisterInstallations(
> >>>>>>>
> >>>>>>> What do you mean by that regex? The problem is simply the
> >>>>> “%2F”
> >>>>>>> in the token (which is an URLencoded simplepush url) and it’s
> >>>>>>> being revoked long before it hits the RestEasy (which does the
> >>>>>>> routing according to what’s in the @Path).
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> On 25 July 2014 10:32, Tadeas Kriz <tkriz at redhat.com> wrote:
> >>>>>>>>>
> >>>>>>>>> —
> >>>>>>>>> Tadeas Kriz
> >>>>>>>>>
> >>>>>>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko at redhat.com>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz
> >>>>> <tkriz at redhat.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> It should not. For hibernate, it’s just a string like
> >>> any
> >>>>>>>>> other.
> >>>>>>>>>>> The problem might be in the configuration of
> >>>>> JAX.RS/RestEasy. If
> >>>>>>>>>>> I’ll have some time today evening, I’ll try to fix
> >>> it, it
> >>>>>>>>> should
> >>>>>>>>>>> be an easy fix.
> >>>>>>>>>>
> >>>>>>>>>> Last famous words? ;-)
> >>>>>>>>>
> >>>>>>>>> I shall never say “an easy fix” again.
> >>>>>>>>>
> >>>>>>>>>> But I agree. Everything is string and URL encode should
> >>>>> happen on
> >>>>>>>>>> client while server should automatically decode and work
> >>>>> always
> >>>>>>>>> with
> >>>>>>>>>> just decoded string. If we need to encode twice, something
> >>> is
> >>>>>>>>> wrong.
> >>>>>>>>>
> >>>>>>>>> Anyway, the 400 Bad request response is made by the tomcat
> >>>>> itself,
> >>>>>>>>> disallowing the use of %2F as a path parameter. This will
> >>>>> probably
> >>>>>>>>> apply on other web containers.
> >>>>>>>>>
> >>>>>>>>> Possible solutions with their disadvantages:
> >>>>>>>>>
> >>>>>>>>> 1. well-documented double-encoding of the URL (might be
> >>>>> confusing)
> >>>>>>>>> 2. use @QueryParam instead of @PathParam (breaks the api
> >>>>>>>>> consistence, as every other call would still use @PathParam)
> >>>>>>>>> 3. allow @QueryParam (again, breaks the api consistence, but
> >>>>> only
> >>>>>>>>> for the SimplePush)
> >>>>>>>>> 4. find another encoding (Base64 for URL = URLEncode then
> >>> Base64
> >>>>>>>>> encode)
> >>>>>>>>> 5. don’t use the url as a deviceToken (might not comply
> >>> with
> >>>>>>>>> Mozzila’s SimplePush specs)
> >>>>>>>>>
> >>>>>>>>> What do you think guys?
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> 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
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>
> >>
> >>
> >> --
> >> 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/20140728/6265612f/attachment-0001.html 