Hi folks! As discussed a few times, we have the following "high-level" construct of data (required for push): - PushApplication ("HR Mobile") - MobileApplication ("HR for iPhone", "HR for iPad", "HR for Android") - Installation ("Matthias uses iPhone HR", "Matthias uses Android HR", "Bruno uses iPad HR") (More details here <https://gist.github.com/matzew/6012edf62d1915689a67>) <https://gist.github.com/matzew/04346e212e317d976532#data-per-installation... per installation per device Now, thinking about what to store for an actual device gives you lot's of choices. For instance, Helios/Orbiter stores a lot of information in the "device" database (e.g. (current) Location Data, Locale etc). Like you can see here: [image: Helios Web UI Screenshot]<https://raw.github.com/helios-framework/helios.io/assets/h... All the information is really app specific (e.g. not every app needs to know the current location...); (A side-note... our client SDK should be flexible to store what ever the application requires...) <https://gist.github.com/matzew/04346e212e317d976532#mandatory-data>Man... Data Regardless of what data is desired or not, the following is the minimum that needs to be stored: - Device Token (generated by the PushNetwork (e.g. APNs, GCM) - used to identify the device with the actual Network, so that it can send a message to that device) - OS and Device Type (we need to store if this is an installation of the iPad version, the iPhone version or the Android version (to use the above HR example)) - OS Version (the version, never hurts) This is the minimum of data, required to store in our "device registration" database; As discussed in AEROGEAR-1101<https://issues.jboss.org/browse/AEROGEAR-1101>;, I would like to store the above "device" data, using the Picketlink IDM (Actually the entire data base (PushApplication, MobileApplication and Installation("device")). <https://gist.github.com/matzew/04346e212e317d976532#user-data->User Data ? Now... you might wonder if there isn't any user data required ..... Well, that is also up to the application and how works. Overall, I see the following two common application models, suppored by the *Push Server*: - device has a user (a known user in an Application (e.g. Marketing) Databases) - device has *NO* user (no need to have a user for the app) <https://gist.github.com/matzew/04346e212e317d976532#user-required>User required This would be an app, that requires an account, before it can be used on the device (e.g. something twitter). For applications like that, a user is required, otherwise hard to send a Push Notification to a specific user (e.g. "You have new tweets") ( *Also twitter works only with a user, on their "application backend/database"* ) <https://gist.github.com/matzew/04346e212e317d976532#no-user-concept-on-th... User concept, on the backend That's a (very) simple app. Think *Sports App*. The app displays "sport news" (fetched via HTTP, when the app is opened). A installed application can also receive "broadcasts messages". *Scenario:* You download the app in the app store, install it, use it; When ever the backend thinks it needs to send Notifications (eg. "New score 3:1 at Germany - Brazil"), it simply uses the token and submits the message to the actual Push Network. For applications like this, the backend does not need a user; <https://gist.github.com/matzew/04346e212e317d976532#application-with-user... with User required Now, let's comeback to the apps, where a user is required, in the backend. Somehow the business backend (e.g. HR system) needs to identify a certain user (and their devices), so that it can "submit" Push Notification jobs. Bruno, Shane (from Picketlink) and I talked already to store something like a unique ID (e.g. user-id, login-name or user-name) in the "Device" Table (per device): TOKEN | user | DEVICE-TYPE | OS-VERSION _________________________________________________________________________ 823ssar | abstractj | Android | Android4.x.y.blah 1234456 | mwessend | iPad | iOS4.0.1 ghh2712 | mwessend | iPhone | iOS6.1.2 Doing so, we can use that "unique ID" to *bridge* between the actual "application database" and the stored informations about the device(s), stored in the *push-server-database*; per user! *NOTE* Since the Push Server (and the "device database") is a standalone server (access via HTTP / Java Library), the real (business) backend (e.g. HR App), can than say: *Send message X to to following users* (a list of unique user IDs would be send to the push server, so that the Push Server submit these messages to the actual Push-Networks (ANPs/GCM)so that Apple and Google (for iOS/Android) can deliver the actual notification to the client/device. <https://gist.github.com/matzew/04346e212e317d976532#client-sdk>Client SDK Again, As said above, we should (and will) offer hooks to have a convenient way to register the unique ID, together with the token,OS,version etc. *BUT* *that is not that important here... ;-)* * * *Thoughts?* * * * * -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

on a side note... since the data the device sends to the "push server" / "registration database", may differ (from case to case)... I think having a flexible (read: schemaless) database for the "model" would be good... On Wed, Apr 17, 2013 at 10:39 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > Hi folks! > > As discussed a few times, we have the following "high-level" construct of > data (required for push): > > - PushApplication ("HR Mobile") > - MobileApplication ("HR for iPhone", "HR for iPad", "HR for Android") > - Installation ("Matthias uses iPhone HR", "Matthias uses Android > HR", "Bruno uses iPad HR") > > (More details here <https://gist.github.com/matzew/6012edf62d1915689a67>) > <https://gist.github.com/matzew/04346e212e317d976532#data-per-installation... > per installation per device > > Now, thinking about what to store for an actual device gives you lot's of > choices. For instance, Helios/Orbiter stores a lot of information in the > "device" database (e.g. (current) Location Data, Locale etc). > > Like you can see here: > > [image: Helios Web UI Screenshot]<https://raw.github.com/helios-framework/helios.io/assets/h... > > All the information is really app specific (e.g. not every app needs to > know the current location...); (A side-note... our client SDK should be > flexible to store what ever the application requires...) > <https://gist.github.com/matzew/04346e212e317d976532#mandatory-data>Man... > Data > > Regardless of what data is desired or not, the following is the minimum > that needs to be stored: > > - Device Token (generated by the PushNetwork (e.g. APNs, GCM) - used > to identify the device with the actual Network, so that it can send a > message to that device) > - OS and Device Type (we need to store if this is an installation of > the iPad version, the iPhone version or the Android version (to use the > above HR example)) > - OS Version (the version, never hurts) > > This is the minimum of data, required to store in our "device > registration" database; > > As discussed in AEROGEAR-1101<https://issues.jboss.org/browse/AEROGEAR-1101>;, > I would like to store the above "device" data, using the Picketlink IDM > (Actually the entire data base (PushApplication, MobileApplication and > Installation("device")). > <https://gist.github.com/matzew/04346e212e317d976532#user-data->User > Data ? > > Now... you might wonder if there isn't any user data required ..... Well, > that is also up to the application and how works. > > Overall, I see the following two common application models, suppored by > the *Push Server*: > > - device has a user (a known user in an Application (e.g. Marketing) > Databases) > - device has *NO* user (no need to have a user for the app) > > <https://gist.github.com/matzew/04346e212e317d976532#user-required>User > required > > This would be an app, that requires an account, before it can be used on > the device (e.g. something twitter). For applications like that, a user is > required, otherwise hard to send a Push Notification to a specific user > (e.g. "You have new tweets") ( *Also twitter works only with a user, on > their "application backend/database"* ) > <https://gist.github.com/matzew/04346e212e317d976532#no-user-concept-on-th... > User concept, on the backend > > That's a (very) simple app. Think *Sports App*. The app displays "sport > news" (fetched via HTTP, when the app is opened). A installed application > can also receive "broadcasts messages". > > *Scenario:* You download the app in the app store, install it, use it; > When ever the backend thinks it needs to send Notifications (eg. "New score > 3:1 at Germany - Brazil"), it simply uses the token and submits the message > to the actual Push Network. For applications like this, the backend does > not need a user; > <https://gist.github.com/matzew/04346e212e317d976532#application-with-user... > with User required > > Now, let's comeback to the apps, where a user is required, in the > backend. Somehow the business backend (e.g. HR system) needs to identify a > certain user (and their devices), so that it can "submit" Push Notification > jobs. > > Bruno, Shane (from Picketlink) and I talked already to store something > like a unique ID (e.g. user-id, login-name or user-name) in the "Device" > Table (per device): > > TOKEN | user | DEVICE-TYPE | OS-VERSION > _________________________________________________________________________ > 823ssar | abstractj | Android | Android4.x.y.blah > 1234456 | mwessend | iPad | iOS4.0.1 > ghh2712 | mwessend | iPhone | iOS6.1.2 > > Doing so, we can use that "unique ID" to *bridge* between the actual > "application database" and the stored informations about the device(s), > stored in the *push-server-database*; per user! > > *NOTE* Since the Push Server (and the "device database") is a standalone > server (access via HTTP / Java Library), the real (business) backend (e.g. > HR App), can than say: > > *Send message X to to following users* (a list of unique user IDs would > be send to the push server, so that the Push Server submit these messages > to the actual Push-Networks (ANPs/GCM)so that Apple and Google (for > iOS/Android) can deliver the actual notification to the client/device. > <https://gist.github.com/matzew/04346e212e317d976532#client-sdk>Client > SDK > > Again, As said above, we should (and will) offer hooks to have a > convenient way to register the unique ID, together with the > token,OS,version etc. *BUT* *that is not that important here... ;-)* > > * > * > > *Thoughts?* > > * > * > > * > * > > -- > 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

Excellent write up. have we defined the terminology yet. i know that is something we talked about, since we have different definitions for things. and is this just for "installed" apps( not web apps )? On Apr 17, 2013, at 4:39 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hi folks! As discussed a few times, we have the following "high-level" construct of data (required for push): - PushApplication ("HR Mobile") - MobileApplication ("HR for iPhone", "HR for iPad", "HR for Android") - Installation ("Matthias uses iPhone HR", "Matthias uses Android HR", "Bruno uses iPad HR") (More details here <https://gist.github.com/matzew/6012edf62d1915689a67>) <https://gist.github.com/matzew/04346e212e317d976532#data-per-installation... per installation per device Now, thinking about what to store for an actual device gives you lot's of choices. For instance, Helios/Orbiter stores a lot of information in the "device" database (e.g. (current) Location Data, Locale etc). Like you can see here: [image: Helios Web UI Screenshot]<https://raw.github.com/helios-framework/helios.io/assets/h... All the information is really app specific (e.g. not every app needs to know the current location...); (A side-note... our client SDK should be flexible to store what ever the application requires...) <https://gist.github.com/matzew/04346e212e317d976532#mandatory-data>Man... Data Regardless of what data is desired or not, the following is the minimum that needs to be stored: - Device Token (generated by the PushNetwork (e.g. APNs, GCM) - used to identify the device with the actual Network, so that it can send a message to that device) - OS and Device Type (we need to store if this is an installation of the iPad version, the iPhone version or the Android version (to use the above HR example)) - OS Version (the version, never hurts) This is the minimum of data, required to store in our "device registration" database; As discussed in AEROGEAR-1101<https://issues.jboss.org/browse/AEROGEAR-1101>;, I would like to store the above "device" data, using the Picketlink IDM (Actually the entire data base (PushApplication, MobileApplication and Installation("device")). <https://gist.github.com/matzew/04346e212e317d976532#user-data->User Data ? Now... you might wonder if there isn't any user data required ..... Well, that is also up to the application and how works. Overall, I see the following two common application models, suppored by the *Push Server*: - device has a user (a known user in an Application (e.g. Marketing) Databases) - device has *NO* user (no need to have a user for the app) <https://gist.github.com/matzew/04346e212e317d976532#user-required>User required This would be an app, that requires an account, before it can be used on the device (e.g. something twitter). For applications like that, a user is required, otherwise hard to send a Push Notification to a specific user (e.g. "You have new tweets") ( *Also twitter works only with a user, on their "application backend/database"* ) <https://gist.github.com/matzew/04346e212e317d976532#no-user-concept-on-th... User concept, on the backend That's a (very) simple app. Think *Sports App*. The app displays "sport news" (fetched via HTTP, when the app is opened). A installed application can also receive "broadcasts messages". *Scenario:* You download the app in the app store, install it, use it; When ever the backend thinks it needs to send Notifications (eg. "New score 3:1 at Germany - Brazil"), it simply uses the token and submits the message to the actual Push Network. For applications like this, the backend does not need a user; <https://gist.github.com/matzew/04346e212e317d976532#application-with-user... with User required Now, let's comeback to the apps, where a user is required, in the backend. Somehow the business backend (e.g. HR system) needs to identify a certain user (and their devices), so that it can "submit" Push Notification jobs. Bruno, Shane (from Picketlink) and I talked already to store something like a unique ID (e.g. user-id, login-name or user-name) in the "Device" Table (per device): TOKEN | user | DEVICE-TYPE | OS-VERSION _________________________________________________________________________ 823ssar | abstractj | Android | Android4.x.y.blah 1234456 | mwessend | iPad | iOS4.0.1 ghh2712 | mwessend | iPhone | iOS6.1.2 Doing so, we can use that "unique ID" to *bridge* between the actual "application database" and the stored informations about the device(s), stored in the *push-server-database*; per user! *NOTE* Since the Push Server (and the "device database") is a standalone server (access via HTTP / Java Library), the real (business) backend (e.g. HR App), can than say: *Send message X to to following users* (a list of unique user IDs would be send to the push server, so that the Push Server submit these messages to the actual Push-Networks (ANPs/GCM)so that Apple and Google (for iOS/Android) can deliver the actual notification to the client/device. <https://gist.github.com/matzew/04346e212e317d976532#client-sdk>Client SDK Again, As said above, we should (and will) offer hooks to have a convenient way to register the unique ID, together with the token,OS,version etc. *BUT* *that is not that important here... ;-)* * * *Thoughts?* * * * * -- 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