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@apache.org> wrote:
>>
>>
>>
>> On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko <kpiwko@redhat.com>
>> wrote:
>>> On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf
>>> <matzew@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@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz <tkriz@redhat.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> —
>>>>>>> Tadeas Kriz
>>>>>>>
>>>>>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius
>>>>>>> <daniel.bevenius@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@redhat.com> wrote:
>>>>>>>>>
>>>>>>>>> —
>>>>>>>>> Tadeas Kriz
>>>>>>>>>
>>>>>>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko <kpiwko@redhat.com>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz
>>>>> <tkriz@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@lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev@lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev@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@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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev