Some more APIs, for some basic (initial) functionality:<div><br></div><div><a href="https://gist.github.com/matzew/c5fbc23bc97dfead46e1">https://gist.github.com/matzew/c5fbc23bc97dfead46e1</a></div><div><br></div><div>User/Dev enrollment can be addressed by (hopefully) reusing the ag-security.</div>
<div><br></div><div><br><br><div class="gmail_quote">On Wed, Mar 13, 2013 at 11:15 AM, Matthias Wessendorf <span dir="ltr">&lt;<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div><br></div><div>I have updated the gist to reflect Bruno&#39;s use-case. I also did a little differentiation on &quot;push apps&quot; and &quot;mobile app&quot;</div>
<div><br></div><div>TL;DR:</div><div>Push App: my backend that sends messages to several mobile apps, on a device (think: twitter backend)</div>
<div>Mobile App: an iOS/android version of the mobile view (think: twitter-iOS) </div><div>MobileInstance: a real installed version of the iOS version (think: Matthias has the twitter-iOS app installed)</div><div><br></div>

<div>The BASIC domain model for the &quot;application abstraction&quot;, is covered in here:</div><div><br></div><div><a href="https://gist.github.com/matzew/3e7e6218d6cea94f65ad" target="_blank">https://gist.github.com/matzew/3e7e6218d6cea94f65ad</a></div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div><br></div><div><br></div><div>-Matthias</div></font></span><div class="HOEnZb"><div class="h5"><div><br><br><div class="gmail_quote">On Wed, Mar 13, 2013 at 8:31 AM, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Great info here Matthias, I&#39;d like to test these scenarios with PicketLink. And thinking aloud here what about scenarios like:<br>


<br>
- Admin can disable push notifications to devices (simple as is at first glance initially)<br>
<br>
<br>
--<br>
&quot;The measure of a man is what he does with power&quot; - Plato<br>
-<br>
@abstractj<br>
-<br>
Volenti Nihil Difficile<br>
<div><div><br>
<br>
<br>
On Tuesday, March 12, 2013 at 7:50 AM, Matthias Wessendorf wrote:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; after two weeks of prototyping and evaluating, I started the design phase of the AG Unified Push Server.<br>
&gt;<br>
&gt; I created a GIST [1] that defines the INITIAL (not final) first DRAFT of the supported use cases. Yes, they are very minimal :), but once we have something running, we can add more features. Please review and comment here...<br>


&gt;<br>
&gt; (COPY AND PAST FROM GIST):<br>
&gt;<br>
&gt; AG Unified Push - Use Cases<br>
&gt;<br>
&gt; Right now there are the following roles:<br>
&gt;<br>
&gt; Developer: Some one that setup up the backend for different mobile applications, to enable push (e.g. iOS certs or Google API keys(more later)<br>
&gt; User: Install an AG-App on his phone<br>
&gt; Admin needed? yes, once we have a management user interface. NOT part of the first iteration....<br>
&gt;<br>
&gt; Use Cases<br>
&gt;<br>
&gt; Below are the BASIC use-cases, that the AG Unified Push needs to initially support.<br>
&gt;<br>
&gt; Enroll AeroGear-Push-User (based on identified roles)<br>
&gt; Remove AeroGear-Push-User<br>
&gt; Developer can register mobile App (for different Push Networks, e.g. Apple, Android)<br>
&gt; Developer can unregister mobile App (for different Push Networks, e.g. Apple, Android)<br>
&gt; User registers his phone with the backend (Device Token + APP-ID are send to the backend)<br>
&gt; User unregisters his phone with the backend (e.g. app got deinstalled, user deleted etc)<br>
&gt; User receives Push Messages (handled by the native OS, once accepted to receive messages)<br>
&gt; Send push messages, done by a user or a developer<br>
&gt;<br>
&gt; Enroll<br>
&gt;<br>
&gt; Register different user types (based on desired role) with the AG-Unified-Push server. The Developer role always requires a username/password. The User is not always required on the server. Some mobile apps don&#39;t know the concept of a logged in user (e.g. Sport Broadcast apps), but others do require a User before using the mobile app (e.g. Twitter)<br>


&gt;<br>
&gt; Remove registered User<br>
&gt;<br>
&gt; It should be possible to remove Users (app users). That can me their account is erased or their device tokes are removed....<br>
&gt;<br>
&gt; Add mobile app<br>
&gt;<br>
&gt; A registered Developer can register multiple Apps with the AeroGear Push Server. Each app has a (generated) AeroGear-Application-Key, besides that, the logical concept of a APP, on the server, requires access to the Push Networks (Google or Apple). Therefore such a registered APP needs a certificate and passphrase (iOS) or a Google API key (Android)<br>


&gt;<br>
&gt; Remove mobile app<br>
&gt;<br>
&gt; A registered Developer should be able to remove the apps from the server.<br>
&gt;<br>
&gt; Device Registration<br>
&gt;<br>
&gt; Once a User installs and launches the mobile app, the embedding OS generates a Device-Token (or Registration ID on Android). The mobile Application needs to send this Token/ID and the AeroGear-Application-Key to the AeroGear Server, so that the server can register this phone/app with the particular app, to be able to receive push messages.<br>


&gt;<br>
&gt;<br>
&gt; Note: On iOS the user as to agree to receive push messages<br>
&gt;<br>
&gt; Remove registered Device<br>
&gt;<br>
&gt; If an app gets uninstalled, the phone is no longer able to receive push messages. Therefore inactive Device-Tokens/Registration-IDs should be removed, on the server. However... there is no harm if invalid keys are used, on the server, when trying to send push messages...<br>


&gt;<br>
&gt; Receives Push Messages<br>
&gt;<br>
&gt; Every installed app, is able to receive Push Messages through the APIs, offered by the platforms (iOS, Android). Initially there will be NO client SDK.<br>
&gt;<br>
&gt;<br>
&gt; Note: On iOS the user as to agree to receive push messages<br>
&gt;<br>
&gt; Send push messages<br>
&gt; Broadcast<br>
&gt;<br>
&gt; The Unified Push server acts as a broker to deliver messages (via Native Push) to several devices. Authorized Users (based on their roles) can send push messages to a specific application. For instance a Developer that ONLY owns &quot;AeroGear-App1&quot; is only able to broadcast messages to that particular app. He is NOT able to send a message to &quot;AeroGear-App2&quot;...<br>


&gt;<br>
&gt; Filtered messaging<br>
&gt;<br>
&gt; Sending message to a specific user.... We need a DSL to filter users etc.... This will be done later...<br>
&gt;<br>
&gt; In-APP messaging<br>
&gt;<br>
&gt; Later, there will be an option to have the app also submit push messages, to broadcast to other users of the app (or to a specific user). This will be done later...<br>
&gt;<br>
&gt; API access<br>
&gt;<br>
&gt; Initial focus is that the above functionality is ONLY accessable via RESTful/HTTP APIs!<br>
&gt;<br>
&gt;<br>
&gt; Later we will have a few more SDKs:<br>
&gt;<br>
&gt; Client APIs (for Android, iOS)<br>
&gt; Server APIs (send a push message out of your JavaEE app, without submitting (manually) the HTTP calls)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Cheers!<br>
&gt; Matthias<br>
&gt;<br>
&gt; [1] <a href="https://gist.github.com/matzew/7475652fa3b0cbb11c1c" target="_blank">https://gist.github.com/matzew/7475652fa3b0cbb11c1c</a><br>
&gt; --<br>
&gt; Matthias Wessendorf<br>
&gt;<br>
&gt; blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
&gt; sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
&gt; twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
</div></div>&gt; _______________________________________________<br>
&gt; aerogear-dev mailing list<br>
&gt; <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a> (mailto:<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>)<br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>

twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div>