[aerogear-dev] [SimplePush] pushEndpoint

Matthias Wessendorf matzew at apache.org
Thu Aug 8 05:03:05 EDT 2013


On Thu, Aug 8, 2013 at 10:59 AM, Daniel Bevenius
<daniel.bevenius at gmail.com>wrote:

> >Looks like we need/should get rid of the "pushNetworkURL" on the SP
> Variant class and store a (SP installation) specific (simple)PushEndpoint.
> +1
>
> >I know that the SP spec names it pushEndpoint, but I feel it's better to
> name it "simplePushEndpoint", to explicitly make sure that this is only for
> Installations of a SimplePushVariant.
> +1 That makes sense naming it simplePushEndpoint I think.
>
> >I wonder if, instead of the ENTIRE URL, we only could just store the
> "hash" (here "d9b74644") and continue to use the pushNetworkURL on the SP
> Variant
> -1 for this with the reasons you outlined. I think it might be more
> flexible if the UnifiedPush Server does not have to deal with a
> 'pushNetworkURL' for SimplePush.
>


thanks for the feedback - and I am happy to see a -1 on the last item
(regardless of all the redundant data).

I was mainly thinking out loud :-)


Glad it makes sense :) (for now o_O )

-M


>
> /Dan
>
>
>
>
>
> On 8 August 2013 10:51, Matthias Wessendorf <matzew at apache.org> wrote:
>
>> Hi,
>>
>> here is an update for UnifiedPush (not yet working), that indicates a
>> strategy:
>>
>>
>> https://github.com/matzew/aerogear-unified-push-server/commit/dcf1c96d63702e4f34ad97794df6f31125755d6f
>>
>>
>> Looks like we need/should get rid of the "pushnetwork URL" on the SP
>> Variant class and store a (SP installation) specific (simple)PushEndpoint.
>> I know that the SP spec names it pushEndpoint, but I feel it's better to
>> name it "simplePushEndpoint", to explicitly make sure that this is only for
>> Installations of a SimplePushVariant.
>>
>>
>> With that change we now store a lot of redundant metadata (for all the SP
>> installations), which is most of the URL. Looking at the endpoint JSON
>> object:
>> {
>>   "messageType": "register",
>>   "channelID": "d9b74644-4f97-46aa-b8fa-9393985cd6cd",
>>   "status": 200,
>>   "pushEndpoint": "http://pushserver.example.org/d9b74644"
>> }
>>
>> I wonder if, instead of the ENTIRE URL, we only could just store the
>> "hash" (here "d9b74644") and continue to use the pushNetworkURL on the SP
>> Variant (here: "http://pushserver.example.org").
>>
>> HOWEVER, I think this does not work when the URL of the "request
>> pushendpoint" server (e.g.  "pushserver-foo.something.org") is different
>> from the endpoint that receives the HTTP PUTs, from the
>> AppServer/UnifiedPushServer.
>>
>> SP connect:
>>
>> SPClient = AeroGear.SimplePushClient({
>>     simplePushServerURL: "http://foobar.server.com:7777/simplepush",
>>     onConnect: spConnect,
>>     onClose: spClose
>> });
>>
>>
>> received endpoint payload:
>>
>> {
>> ...
>> "pushEndpoint" : "http://something.different.server.com/blahBlahBlub"
>> }
>>
>>
>>
>>
>> -Matthias
>>
>>
>>
>>
>> On Thu, Aug 8, 2013 at 9:53 AM, Daniel Bevenius <
>> daniel.bevenius at gmail.com> wrote:
>>
>>> Hi all!
>>>
>>> Yesterday Kris pointed out that we are not following the SimplePush
>>> Spec[1] when it comes to the 'pushEndpoint' that is returned when
>>> registering a channel. The spec shows that an absolute URL is returned but
>>> we are returning a relative URL.
>>>
>>> For the AeroGear SimplePush Server this is being address
>>> by AGPUSH-261[2], and an instance that returns absolute URL is available at
>>> http://endpointurldns-dbevenius.rhcloud.com:8000/simplepush.
>>>
>>> This change will affect the JavaScript client, the UnifiedPush Server,
>>> the Admin UI and possibly QE integration tests.
>>>
>>> I won't go into all the changes for the components listed above as
>>> others can provide more accurate information about them if needed. Just
>>> wanted to give a heads up to all about this.
>>>
>>> /Dan
>>>
>>> [1]
>>> https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#PushServer_-.3E_UserAgent_2
>>> [2] https://issues.jboss.org/browse/AGPUSH-261
>>>
>>> _______________________________________________
>>> 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/20130808/4f60509e/attachment-0001.html 


More information about the aerogear-dev mailing list