Here is the REST API for "Push App" (+mobile app) registrations: https://gist.github.com/matzew/2da6fc349a4aaf629bce Questions: The post to "/applications/das231432qwdsa2/iOS" and/or "/applications/das231432qwdsa2/android" are different (payload-wise).... Not sure if that is best solution.... However, we need to differentiate between different "mobile os variants" anyways.... My (CURRENT) feelings is that a different "endpoint" is better instead of an ugly, large - but generic - API that does everything, and the server figures out what type of mobile app has been registered …

NEXT: Device Registrations + Sender Endpoints (Followed by "management" (get, put, delete.....) Greetings, Matthias On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hello, here is the 'overview' section of the Unified push....: AeroGear Unified Push (DRAFT 0.0.2) This is an early version of a 'spec' for the AeroGear Unified Push server. Overview The Unified Push solution contains the following components: Native Push Component: sends native push message to registered apps Web Push Component: sends web push message to online client (e.g. WebSocket/SockJS clients) Client SDK API Native Push Client for iOS Native Push Client for Android Web Push Client for JavaScript Details are discussed on the each of the different components NOTE: LINK need to be enabled :) :) HOWEVER....... Here is what I'd like to add to the home page for the native push component - based on last weeks discussion: https://gist.github.com/matzew/69d33a18d4fac9fdedd4 PLEASE comment on the gist.... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Mar 20, 2013 at 1:31 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Mar 20, 2013, at 6:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Here is the REST API for "Push App" (+mobile app) registrations: > > https://gist.github.com/matzew/2da6fc349a4aaf629bce > > > Questions: > > The post to "/applications/das231432qwdsa2/iOS" and/or "/applications/das231432qwdsa2/android" are different (payload-wise).... > > Not sure if that is best solution.... However, we need to differentiate between different "mobile os variants" anyways.... > > My (CURRENT) feelings is that a different "endpoint" is better instead of an ugly, large - but generic - API that does everything, and the server figures out what type of mobile app has been registered … I agree that different endpoints makes sense, especially if a user is only interested in iOS devices for example and so only build an app that works on iOS, since this would allow for easy registration of a single type of application. I would however like to see, and believe users would like to see, some sort of unified API so that they only have register an app once for both Android and iOS. Maybe this won't be an issue once we have more than just a REST interface but just wanted to throw it out there. Like a post to "/applications where the payload is: { // push app properties "description":"just a test", "name":"TestApp", // REQUIRED Apple Push Network props: "cert":"CERT_UPLOAD_VAL", "passphrase": "top-secret", REQUIRED GCM Push Network props: "google-api-key": "dsdsaadsadsdasadsdsa" } and the 201 Response could look like: { "id":"PushAppKey" "apps":[ {"iOS-ID":"adda213213"}, {"android-ID":"454dda213213"}, ] } This UBER :) API could work, for really just one "server side" abstraction, that has exaclty ONE iOS and one Android APP (of course the request body of the POST could contain arrays for different CERTS, passphrases, API-Keys). For a convenience we surly can have that - Is that what you mean ?

-M > > > NEXT: Device Registrations + Sender Endpoints > > (Followed by "management" (get, put, delete.....) > > > Greetings, > Matthias > > > > On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Hello, > > here is the 'overview' section of the Unified push....: > > > AeroGear Unified Push (DRAFT 0.0.2) > This is an early version of a 'spec' for the AeroGear Unified Push server. > > Overview > The Unified Push solution contains the following components: > > Native Push Component: sends native push message to registered apps > Web Push Component: sends web push message to online client (e.g. WebSocket/SockJS clients) > Client SDK API > Native Push Client for iOS > Native Push Client for Android > Web Push Client for JavaScript > Details are discussed on the each of the different components > > NOTE: LINK need to be enabled :) :) > HOWEVER....... > Here is what I'd like to add to the home page for the native push component - based on last weeks discussion: > https://gist.github.com/matzew/69d33a18d4fac9fdedd4 > PLEASE comment on the gist.... > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Maybe we can have this UBER api but we still need to have the "atomic" service to be able to add a mobile apps afterwards, no ?

discussion : inside a same device type, let's say iOS, there can multiple mobile apps pointing to the same push app (freemium/premium etc ...). So we need an extra array :

[ { name: "app1", description: "desc1", // I would recommend wrapping these in platform names in case key names ever change and match ios: { [ {cert: "certval1", passphrase: "passphrase1"}, {cert: "certval2", passphrase: "passphrase2"} ] }, android: { [ {"google-api-key": "key1"}, {"google-api-key": "key2"} ] } }, { name: "app2", description: "desc2", // I would recommend wrapping these in platform names in case key names ever change and match ios: { [ {cert: "certval3", passphrase: "passphrase3"}, {cert: "certval4", passphrase: "passphrase4"} ] }, android: { [ {"google-api-key": "key3"}, {"google-api-key": "key4"} ] } } ]

On Wed, Mar 20, 2013 at 1:54 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Mar 20, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > On Wed, Mar 20, 2013 at 1:31 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Mar 20, 2013, at 6:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> Here is the REST API for "Push App" (+mobile app) registrations: >> >> https://gist.github.com/matzew/2da6fc349a4aaf629bce >> >> >> Questions: >> >> The post to "/applications/das231432qwdsa2/iOS" and/or >> "/applications/das231432qwdsa2/android" are different (payload-wise).... >> >> Not sure if that is best solution.... However, we need to differentiate >> between different "mobile os variants" anyways.... >> >> My (CURRENT) feelings is that a different "endpoint" is better instead >> of an ugly, large - but generic - API that does everything, and the server >> figures out what type of mobile app has been registered … >> >> >> I agree that different endpoints makes sense, especially if a user is >> only interested in iOS devices for example and so only build an app that >> works on iOS, since this would allow for easy registration of a single type >> of application. I would however like to see, and believe users would like >> to see, some sort of unified API so that they only have register an app >> once for both Android and iOS. Maybe this won't be an issue once we have >> more than just a REST interface but just wanted to throw it out there. >> > > > Like a post to "/applications > > where the payload is: > > { > // push app properties > "description":"just a test", > "name":"TestApp", > > // REQUIRED Apple Push Network props: > "cert":"CERT_UPLOAD_VAL", > "passphrase": "top-secret", > > REQUIRED GCM Push Network props: > "google-api-key": "dsdsaadsadsdasadsdsa" > > } > > and the 201 Response could look like: > { > "id":"PushAppKey" > "apps":[ > {"iOS-ID":"adda213213"}, > {"android-ID":"454dda213213"}, > ] > } > > This UBER :) API could work, for really just one "server side" > abstraction, that has exaclty ONE iOS and one Android APP (of course the > request body of the POST could contain arrays for different CERTS, > passphrases, API-Keys). > > For a convenience we surly can have that - Is that what you mean ? > > > Yep, that is pretty much what I meant, and would be in favor of passing > an array of applications instead of an array of certs, etc. which would > allow for multiple applications on multiple platforms like this: > > [ > { > name: "app1", > description: "desc1", > // I would recommend wrapping these in platform names in case key names > ever change and match > ios: { > cert: "certval1", > passphrase: "passphrase1" > }, > android: { > "google-api-key": "key1" > } > }, > { > name: "app2", > description: "desc2", > // I would recommend wrapping these in platform names in case key names > ever change and match > ios: { > cert: "certval2", > passphrase: "passphrase2" > }, > android: { > "google-api-key": "key2" > } > } > ] > > > -M > > >> >> >> NEXT: Device Registrations + Sender Endpoints >> >> (Followed by "management" (get, put, delete.....) >> >> >> Greetings, >> Matthias >> >> >> >> On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> Hello, >>> >>> here is the 'overview' section of the Unified push....: >>> >>> >>> AeroGear Unified Push (DRAFT 0.0.2) >>> >>> This is an *early* version of a 'spec' for the AeroGear Unified Push >>> server. >>> <https://gist.github.com/matzew/ec5c3c2dfa955c58c328#overview>Overview >>> >>> The *Unified Push* solution contains the following components: >>> >>> - Native Push Component: *sends native push message to registered >>> apps* >>> - Web Push Component: *sends web push message to online client >>> (e.g. WebSocket/SockJS clients)* >>> - Client SDK API >>> - Native Push Client for iOS >>> - Native Push Client for Android >>> - Web Push Client for JavaScript >>> >>> Details are discussed on the each of the different components >>> >>> >>> NOTE: LINK need to be enabled :) :) >>> >>> HOWEVER....... >>> >>> Here is what I'd like to add to the home page for the native push >>> component - based on last weeks discussion: >>> >>> https://gist.github.com/matzew/69d33a18d4fac9fdedd4 >>> >>> PLEASE comment on the gist.... >>> >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Mar 20, 2013 at 2:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > Maybe we can have this UBER api but we still need to have the "atomic" > service to be able to add a mobile apps afterwards, no ? > Second point is, if I understood it well from the previous gists and > discussion : inside a same device type, let's say iOS, there can multiple > mobile apps pointing to the same push app (freemium/premium etc ...). So we > need an extra array : > > > [ > { > name: "app1", > ..... > name: "app2", > ... not sure if I really want to register the entire app store, with one HTTP POST :) what u suggested is basically, one POST registers: -Foo-Inc's HR app (and various iOS/Android) -Foo-Inc's CRM app (and various iOS/Android) -Foo-Inc's WHAT-NOT-APP app (and various iOS/Android) ... I think that a POST to /applications, should only register ONE push app (however, with different mobile variations (paid/free)) -M > description: "desc2", > // I would recommend wrapping these in platform names in case key names > ever change and match > ios: { > [ > {cert: "certval3", > passphrase: "passphrase3"}, > > {cert: "certval4", > passphrase: "passphrase4"} > ] > }, > android: { > [ > {"google-api-key": "key3"}, > {"google-api-key": "key4"} > ] > } > } > ] > > > > > On Wed, Mar 20, 2013 at 1:54 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Mar 20, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> On Wed, Mar 20, 2013 at 1:31 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> >>> On Mar 20, 2013, at 6:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> Here is the REST API for "Push App" (+mobile app) registrations: >>> >>> https://gist.github.com/matzew/2da6fc349a4aaf629bce >>> >>> >>> Questions: >>> >>> The post to "/applications/das231432qwdsa2/iOS" and/or >>> "/applications/das231432qwdsa2/android" are different (payload-wise).... >>> >>> Not sure if that is best solution.... However, we need to differentiate >>> between different "mobile os variants" anyways.... >>> >>> My (CURRENT) feelings is that a different "endpoint" is better instead >>> of an ugly, large - but generic - API that does everything, and the server >>> figures out what type of mobile app has been registered … >>> >>> >>> I agree that different endpoints makes sense, especially if a user is >>> only interested in iOS devices for example and so only build an app that >>> works on iOS, since this would allow for easy registration of a single type >>> of application. I would however like to see, and believe users would like >>> to see, some sort of unified API so that they only have register an app >>> once for both Android and iOS. Maybe this won't be an issue once we have >>> more than just a REST interface but just wanted to throw it out there. >>> >> >> >> Like a post to "/applications >> >> where the payload is: >> >> { >> // push app properties >> "description":"just a test", >> "name":"TestApp", >> >> // REQUIRED Apple Push Network props: >> "cert":"CERT_UPLOAD_VAL", >> "passphrase": "top-secret", >> >> REQUIRED GCM Push Network props: >> "google-api-key": "dsdsaadsadsdasadsdsa" >> >> } >> >> and the 201 Response could look like: >> { >> "id":"PushAppKey" >> "apps":[ >> {"iOS-ID":"adda213213"}, >> {"android-ID":"454dda213213"}, >> ] >> } >> >> This UBER :) API could work, for really just one "server side" >> abstraction, that has exaclty ONE iOS and one Android APP (of course the >> request body of the POST could contain arrays for different CERTS, >> passphrases, API-Keys). >> >> For a convenience we surly can have that - Is that what you mean ? >> >> >> Yep, that is pretty much what I meant, and would be in favor of passing >> an array of applications instead of an array of certs, etc. which would >> allow for multiple applications on multiple platforms like this: >> >> [ >> { >> name: "app1", >> description: "desc1", >> // I would recommend wrapping these in platform names in case key >> names ever change and match >> ios: { >> cert: "certval1", >> passphrase: "passphrase1" >> }, >> android: { >> "google-api-key": "key1" >> } >> }, >> { >> name: "app2", >> description: "desc2", >> // I would recommend wrapping these in platform names in case key >> names ever change and match >> ios: { >> cert: "certval2", >> passphrase: "passphrase2" >> }, >> android: { >> "google-api-key": "key2" >> } >> } >> ] >> >> >> -M >> >> >>> >>> >>> NEXT: Device Registrations + Sender Endpoints >>> >>> (Followed by "management" (get, put, delete.....) >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf <matzew(a)apache.org >>> > wrote: >>> >>>> Hello, >>>> >>>> here is the 'overview' section of the Unified push....: >>>> >>>> >>>> AeroGear Unified Push (DRAFT 0.0.2) >>>> >>>> This is an *early* version of a 'spec' for the AeroGear Unified Push >>>> server. >>>> <https://gist.github.com/matzew/ec5c3c2dfa955c58c328#overview> >>>> Overview >>>> >>>> The *Unified Push* solution contains the following components: >>>> >>>> - Native Push Component: *sends native push message to registered >>>> apps* >>>> - Web Push Component: *sends web push message to online client >>>> (e.g. WebSocket/SockJS clients)* >>>> - Client SDK API >>>> - Native Push Client for iOS >>>> - Native Push Client for Android >>>> - Web Push Client for JavaScript >>>> >>>> Details are discussed on the each of the different components >>>> >>>> >>>> NOTE: LINK need to be enabled :) :) >>>> >>>> HOWEVER....... >>>> >>>> Here is what I'd like to add to the home page for the native push >>>> component - based on last weeks discussion: >>>> >>>> https://gist.github.com/matzew/69d33a18d4fac9fdedd4 >>>> >>>> PLEASE comment on the gist.... >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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

Totally agree, So let's focus again on the second one : post /app/:ID:/iOS and your remark that we have different payloads. It's hard to decide, just wondering about API maintenance (more API documentation etc ) potential issues when we will be adding new devices (BB, Windows, Facebook phone;) ), could something like that works : /applications/das231432qwdsa2/register { "deviceType": "ios" // could be "android", "bb" "settings" : { // wildcard key/value pairs } } We keep here a generic API but will maybe have more work on the backend side. Just a suggestion.

Seb On Wed, Mar 20, 2013 at 2:41 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > On Wed, Mar 20, 2013 at 2:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> Maybe we can have this UBER api but we still need to have the "atomic" >> service to be able to add a mobile apps afterwards, no ? >> Second point is, if I understood it well from the previous gists and >> discussion : inside a same device type, let's say iOS, there can multiple >> mobile apps pointing to the same push app (freemium/premium etc ...). So we >> need an extra array : >> >> >> [ >> { >> name: "app1", >> > ..... > >> name: "app2", >> > > ... not sure if I really want to register the entire app store, with one > HTTP POST :) > > what u suggested is basically, one POST registers: > -Foo-Inc's HR app (and various iOS/Android) > -Foo-Inc's CRM app (and various iOS/Android) > -Foo-Inc's WHAT-NOT-APP app (and various iOS/Android) > ... > > I think that a POST to /applications, should only register ONE push app > (however, with different mobile variations (paid/free)) > > > -M > > > > > >> description: "desc2", >> // I would recommend wrapping these in platform names in case key >> names ever change and match >> ios: { >> [ >> {cert: "certval3", >> passphrase: "passphrase3"}, >> >> {cert: "certval4", >> passphrase: "passphrase4"} >> ] >> }, >> android: { >> [ >> {"google-api-key": "key3"}, >> {"google-api-key": "key4"} >> ] >> } >> } >> ] >> >> >> >> >> On Wed, Mar 20, 2013 at 1:54 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> >>> On Mar 20, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> On Wed, Mar 20, 2013 at 1:31 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> >>>> On Mar 20, 2013, at 6:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>> >>>> Here is the REST API for "Push App" (+mobile app) registrations: >>>> >>>> https://gist.github.com/matzew/2da6fc349a4aaf629bce >>>> >>>> >>>> Questions: >>>> >>>> The post to "/applications/das231432qwdsa2/iOS" and/or >>>> "/applications/das231432qwdsa2/android" are different (payload-wise).... >>>> >>>> Not sure if that is best solution.... However, we need to >>>> differentiate between different "mobile os variants" anyways.... >>>> >>>> My (CURRENT) feelings is that a different "endpoint" is better instead >>>> of an ugly, large - but generic - API that does everything, and the server >>>> figures out what type of mobile app has been registered … >>>> >>>> >>>> I agree that different endpoints makes sense, especially if a user is >>>> only interested in iOS devices for example and so only build an app that >>>> works on iOS, since this would allow for easy registration of a single type >>>> of application. I would however like to see, and believe users would like >>>> to see, some sort of unified API so that they only have register an app >>>> once for both Android and iOS. Maybe this won't be an issue once we have >>>> more than just a REST interface but just wanted to throw it out there. >>>> >>> >>> >>> Like a post to "/applications >>> >>> where the payload is: >>> >>> { >>> // push app properties >>> "description":"just a test", >>> "name":"TestApp", >>> >>> // REQUIRED Apple Push Network props: >>> "cert":"CERT_UPLOAD_VAL", >>> "passphrase": "top-secret", >>> >>> REQUIRED GCM Push Network props: >>> "google-api-key": "dsdsaadsadsdasadsdsa" >>> >>> } >>> >>> and the 201 Response could look like: >>> { >>> "id":"PushAppKey" >>> "apps":[ >>> {"iOS-ID":"adda213213"}, >>> {"android-ID":"454dda213213"}, >>> ] >>> } >>> >>> This UBER :) API could work, for really just one "server side" >>> abstraction, that has exaclty ONE iOS and one Android APP (of course the >>> request body of the POST could contain arrays for different CERTS, >>> passphrases, API-Keys). >>> >>> For a convenience we surly can have that - Is that what you mean ? >>> >>> >>> Yep, that is pretty much what I meant, and would be in favor of passing >>> an array of applications instead of an array of certs, etc. which would >>> allow for multiple applications on multiple platforms like this: >>> >>> [ >>> { >>> name: "app1", >>> description: "desc1", >>> // I would recommend wrapping these in platform names in case key >>> names ever change and match >>> ios: { >>> cert: "certval1", >>> passphrase: "passphrase1" >>> }, >>> android: { >>> "google-api-key": "key1" >>> } >>> }, >>> { >>> name: "app2", >>> description: "desc2", >>> // I would recommend wrapping these in platform names in case key >>> names ever change and match >>> ios: { >>> cert: "certval2", >>> passphrase: "passphrase2" >>> }, >>> android: { >>> "google-api-key": "key2" >>> } >>> } >>> ] >>> >>> >>> -M >>> >>> >>>> >>>> >>>> NEXT: Device Registrations + Sender Endpoints >>>> >>>> (Followed by "management" (get, put, delete.....) >>>> >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> >>>> On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf < >>>> matzew(a)apache.org&gt; wrote: >>>> >>>>> Hello, >>>>> >>>>> here is the 'overview' section of the Unified push....: >>>>> >>>>> >>>>> AeroGear Unified Push (DRAFT 0.0.2) >>>>> >>>>> This is an *early* version of a 'spec' for the AeroGear Unified Push >>>>> server. >>>>> <https://gist.github.com/matzew/ec5c3c2dfa955c58c328#overview> >>>>> Overview >>>>> >>>>> The *Unified Push* solution contains the following components: >>>>> >>>>> - Native Push Component: *sends native push message to registered >>>>> apps* >>>>> - Web Push Component: *sends web push message to online client >>>>> (e.g. WebSocket/SockJS clients)* >>>>> - Client SDK API >>>>> - Native Push Client for iOS >>>>> - Native Push Client for Android >>>>> - Web Push Client for JavaScript >>>>> >>>>> Details are discussed on the each of the different components >>>>> >>>>> >>>>> NOTE: LINK need to be enabled :) :) >>>>> >>>>> HOWEVER....... >>>>> >>>>> Here is what I'd like to add to the home page for the native push >>>>> component - based on last weeks discussion: >>>>> >>>>> https://gist.github.com/matzew/69d33a18d4fac9fdedd4 >>>>> >>>>> PLEASE comment on the gist.... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

> when we will be adding new devices (BB, Windows, Facebook phone;) ), > could something like that works : > You still need some server side logic, to understadn the windows (for instance) mapping of the attributes. IMO no matter if the decision of the TYPE is done _inside_ of the payload, or on different endpoint/subendpoint. In vert.x the RouteMatcher is already generic: rm.post("/applications/:key/:variant", new Handler<HttpServerRequest>() So... if theere is a post against "/application/12345/windows" - the "parser decides based on "variant". Your way it would check based on payload type; Again - I am not against it - nor I am for that :) I am just ... not sure if "wildcards" are always that great... > > /applications/das231432qwdsa2/register > > { > "deviceType": "ios" // could be "android", "bb" > "settings" : { > // wildcard key/value pairs > } > } > > We keep here a generic API but will maybe have more work on the backend > side. > Just a suggestion. > Seb > > > > On Wed, Mar 20, 2013 at 2:41 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> >> >> On Wed, Mar 20, 2013 at 2:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >> >>> Maybe we can have this UBER api but we still need to have the "atomic" >>> service to be able to add a mobile apps afterwards, no ? >>> Second point is, if I understood it well from the previous gists and >>> discussion : inside a same device type, let's say iOS, there can multiple >>> mobile apps pointing to the same push app (freemium/premium etc ...). So we >>> need an extra array : >>> >>> >>> [ >>> { >>> name: "app1", >>> >> ..... >> >>> name: "app2", >>> >> >> ... not sure if I really want to register the entire app store, with one >> HTTP POST :) >> >> what u suggested is basically, one POST registers: >> -Foo-Inc's HR app (and various iOS/Android) >> -Foo-Inc's CRM app (and various iOS/Android) >> -Foo-Inc's WHAT-NOT-APP app (and various iOS/Android) >> ... >> >> I think that a POST to /applications, should only register ONE push app >> (however, with different mobile variations (paid/free)) >> >> >> -M >> >> >> >> >> >>> description: "desc2", >>> // I would recommend wrapping these in platform names in case key >>> names ever change and match >>> ios: { >>> [ >>> {cert: "certval3", >>> passphrase: "passphrase3"}, >>> >>> {cert: "certval4", >>> passphrase: "passphrase4"} >>> ] >>> }, >>> android: { >>> [ >>> {"google-api-key": "key3"}, >>> {"google-api-key": "key4"} >>> ] >>> } >>> } >>> ] >>> >>> >>> >>> >>> On Wed, Mar 20, 2013 at 1:54 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> >>>> On Mar 20, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>> >>>> >>>> >>>> On Wed, Mar 20, 2013 at 1:31 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>> >>>>> >>>>> On Mar 20, 2013, at 6:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>> wrote: >>>>> >>>>> Here is the REST API for "Push App" (+mobile app) registrations: >>>>> >>>>> https://gist.github.com/matzew/2da6fc349a4aaf629bce >>>>> >>>>> >>>>> Questions: >>>>> >>>>> The post to "/applications/das231432qwdsa2/iOS" and/or >>>>> "/applications/das231432qwdsa2/android" are different (payload-wise).... >>>>> >>>>> Not sure if that is best solution.... However, we need to >>>>> differentiate between different "mobile os variants" anyways.... >>>>> >>>>> My (CURRENT) feelings is that a different "endpoint" is better >>>>> instead of an ugly, large - but generic - API that does everything, and the >>>>> server figures out what type of mobile app has been registered … >>>>> >>>>> >>>>> I agree that different endpoints makes sense, especially if a user is >>>>> only interested in iOS devices for example and so only build an app that >>>>> works on iOS, since this would allow for easy registration of a single type >>>>> of application. I would however like to see, and believe users would like >>>>> to see, some sort of unified API so that they only have register an app >>>>> once for both Android and iOS. Maybe this won't be an issue once we have >>>>> more than just a REST interface but just wanted to throw it out there. >>>>> >>>> >>>> >>>> Like a post to "/applications >>>> >>>> where the payload is: >>>> >>>> { >>>> // push app properties >>>> "description":"just a test", >>>> "name":"TestApp", >>>> >>>> // REQUIRED Apple Push Network props: >>>> "cert":"CERT_UPLOAD_VAL", >>>> "passphrase": "top-secret", >>>> >>>> REQUIRED GCM Push Network props: >>>> "google-api-key": "dsdsaadsadsdasadsdsa" >>>> >>>> } >>>> >>>> and the 201 Response could look like: >>>> { >>>> "id":"PushAppKey" >>>> "apps":[ >>>> {"iOS-ID":"adda213213"}, >>>> {"android-ID":"454dda213213"}, >>>> ] >>>> } >>>> >>>> This UBER :) API could work, for really just one "server side" >>>> abstraction, that has exaclty ONE iOS and one Android APP (of course the >>>> request body of the POST could contain arrays for different CERTS, >>>> passphrases, API-Keys). >>>> >>>> For a convenience we surly can have that - Is that what you mean ? >>>> >>>> >>>> Yep, that is pretty much what I meant, and would be in favor of >>>> passing an array of applications instead of an array of certs, etc. which >>>> would allow for multiple applications on multiple platforms like this: >>>> >>>> [ >>>> { >>>> name: "app1", >>>> description: "desc1", >>>> // I would recommend wrapping these in platform names in case key >>>> names ever change and match >>>> ios: { >>>> cert: "certval1", >>>> passphrase: "passphrase1" >>>> }, >>>> android: { >>>> "google-api-key": "key1" >>>> } >>>> }, >>>> { >>>> name: "app2", >>>> description: "desc2", >>>> // I would recommend wrapping these in platform names in case key >>>> names ever change and match >>>> ios: { >>>> cert: "certval2", >>>> passphrase: "passphrase2" >>>> }, >>>> android: { >>>> "google-api-key": "key2" >>>> } >>>> } >>>> ] >>>> >>>> >>>> -M >>>> >>>> >>>>> >>>>> >>>>> NEXT: Device Registrations + Sender Endpoints >>>>> >>>>> (Followed by "management" (get, put, delete.....) >>>>> >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>> >>>>> On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf < >>>>> matzew(a)apache.org&gt; wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> here is the 'overview' section of the Unified push....: >>>>>> >>>>>> >>>>>> AeroGear Unified Push (DRAFT 0.0.2) >>>>>> >>>>>> This is an *early* version of a 'spec' for the AeroGear Unified >>>>>> Push server. >>>>>> <https://gist.github.com/matzew/ec5c3c2dfa955c58c328#overview> >>>>>> Overview >>>>>> >>>>>> The *Unified Push* solution contains the following components: >>>>>> >>>>>> - Native Push Component: *sends native push message to >>>>>> registered apps* >>>>>> - Web Push Component: *sends web push message to online client >>>>>> (e.g. WebSocket/SockJS clients)* >>>>>> - Client SDK API >>>>>> - Native Push Client for iOS >>>>>> - Native Push Client for Android >>>>>> - Web Push Client for JavaScript >>>>>> >>>>>> Details are discussed on the each of the different components >>>>>> >>>>>> >>>>>> NOTE: LINK need to be enabled :) :) >>>>>> >>>>>> HOWEVER....... >>>>>> >>>>>> Here is what I'd like to add to the home page for the native push >>>>>> component - based on last weeks discussion: >>>>>> >>>>>> https://gist.github.com/matzew/69d33a18d4fac9fdedd4 >>>>>> >>>>>> PLEASE comment on the gist.... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mar 20, 2013, at 8:41 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Wed, Mar 20, 2013 at 2:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > Maybe we can have this UBER api but we still need to have the "atomic" > service to be able to add a mobile apps afterwards, no ? > Second point is, if I understood it well from the previous gists and > discussion : inside a same device type, let's say iOS, there can multiple > mobile apps pointing to the same push app (freemium/premium etc ...). So we > need an extra array : > > > [ > { > name: "app1", > ..... > name: "app2", > ... not sure if I really want to register the entire app store, with one HTTP POST :) Yeah, I think my main point here was that i wanted to be able to group the Android and iOS registration together. The multiple apps at the same time was more a nice (unnecessary?) side effect so I shouldn't have called that out in my example. what u suggested is basically, one POST registers: -Foo-Inc's HR app (and various iOS/Android) -Foo-Inc's CRM app (and various iOS/Android) -Foo-Inc's WHAT-NOT-APP app (and various iOS/Android) ... I think that a POST to /applications, should only register ONE push app (however, with different mobile variations (paid/free)) -M > description: "desc2", > // I would recommend wrapping these in platform names in case key names > ever change and match > ios: { > [ > {cert: "certval3", > passphrase: "passphrase3"}, > > {cert: "certval4", > passphrase: "passphrase4"} > ] > }, > android: { > [ > {"google-api-key": "key3"}, > {"google-api-key": "key4"} > ] > } > } > ] > > > > > On Wed, Mar 20, 2013 at 1:54 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Mar 20, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> On Wed, Mar 20, 2013 at 1:31 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> >>> On Mar 20, 2013, at 6:43 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> Here is the REST API for "Push App" (+mobile app) registrations: >>> >>> https://gist.github.com/matzew/2da6fc349a4aaf629bce >>> >>> >>> Questions: >>> >>> The post to "/applications/das231432qwdsa2/iOS" and/or >>> "/applications/das231432qwdsa2/android" are different (payload-wise).... >>> >>> Not sure if that is best solution.... However, we need to differentiate >>> between different "mobile os variants" anyways.... >>> >>> My (CURRENT) feelings is that a different "endpoint" is better instead >>> of an ugly, large - but generic - API that does everything, and the server >>> figures out what type of mobile app has been registered … >>> >>> >>> I agree that different endpoints makes sense, especially if a user is >>> only interested in iOS devices for example and so only build an app that >>> works on iOS, since this would allow for easy registration of a single type >>> of application. I would however like to see, and believe users would like >>> to see, some sort of unified API so that they only have register an app >>> once for both Android and iOS. Maybe this won't be an issue once we have >>> more than just a REST interface but just wanted to throw it out there. >>> >> >> >> Like a post to "/applications >> >> where the payload is: >> >> { >> // push app properties >> "description":"just a test", >> "name":"TestApp", >> >> // REQUIRED Apple Push Network props: >> "cert":"CERT_UPLOAD_VAL", >> "passphrase": "top-secret", >> >> REQUIRED GCM Push Network props: >> "google-api-key": "dsdsaadsadsdasadsdsa" >> >> } >> >> and the 201 Response could look like: >> { >> "id":"PushAppKey" >> "apps":[ >> {"iOS-ID":"adda213213"}, >> {"android-ID":"454dda213213"}, >> ] >> } >> >> This UBER :) API could work, for really just one "server side" >> abstraction, that has exaclty ONE iOS and one Android APP (of course the >> request body of the POST could contain arrays for different CERTS, >> passphrases, API-Keys). >> >> For a convenience we surly can have that - Is that what you mean ? >> >> >> Yep, that is pretty much what I meant, and would be in favor of passing >> an array of applications instead of an array of certs, etc. which would >> allow for multiple applications on multiple platforms like this: >> >> [ >> { >> name: "app1", >> description: "desc1", >> // I would recommend wrapping these in platform names in case key >> names ever change and match >> ios: { >> cert: "certval1", >> passphrase: "passphrase1" >> }, >> android: { >> "google-api-key": "key1" >> } >> }, >> { >> name: "app2", >> description: "desc2", >> // I would recommend wrapping these in platform names in case key >> names ever change and match >> ios: { >> cert: "certval2", >> passphrase: "passphrase2" >> }, >> android: { >> "google-api-key": "key2" >> } >> } >> ] >> >> >> -M >> >> >>> >>> >>> NEXT: Device Registrations + Sender Endpoints >>> >>> (Followed by "management" (get, put, delete.....) >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> On Tue, Mar 19, 2013 at 4:45 PM, Matthias Wessendorf <matzew(a)apache.org >>> > wrote: >>> >>>> Hello, >>>> >>>> here is the 'overview' section of the Unified push....: >>>> >>>> >>>> AeroGear Unified Push (DRAFT 0.0.2) >>>> >>>> This is an *early* version of a 'spec' for the AeroGear Unified Push >>>> server. >>>> <https://gist.github.com/matzew/ec5c3c2dfa955c58c328#overview> >>>> Overview >>>> >>>> The *Unified Push* solution contains the following components: >>>> >>>> - Native Push Component: *sends native push message to registered >>>> apps* >>>> - Web Push Component: *sends web push message to online client >>>> (e.g. WebSocket/SockJS clients)* >>>> - Client SDK API >>>> - Native Push Client for iOS >>>> - Native Push Client for Android >>>> - Web Push Client for JavaScript >>>> >>>> Details are discussed on the each of the different components >>>> >>>> >>>> NOTE: LINK need to be enabled :) :) >>>> >>>> HOWEVER....... >>>> >>>> Here is what I'd like to add to the home page for the native push >>>> component - based on last weeks discussion: >>>> >>>> https://gist.github.com/matzew/69d33a18d4fac9fdedd4 >>>> >>>> PLEASE comment on the gist.... >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev