On Thu, Aug 8, 2013 at 10:59 AM, Daniel Bevenius <daniel.bevenius@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@apache.org> wrote:
Hi,

here is an update for UnifiedPush (not yet working), that indicates a strategy:



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,
}

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:



-Matthias




On Thu, Aug 8, 2013 at 9:53 AM, Daniel Bevenius <daniel.bevenius@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


_______________________________________________
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



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf