5:50 a.m.
Hi,
after two weeks of prototyping and evaluating, I started the design phase
of the AG Unified Push Server.
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...
(COPY AND PAST FROM GIST):
AG Unified Push - Use Cases
Right now there are the following roles:
- *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)
- *User*: Install an AG-App on his phone
- *Admin* needed? yes, once we have a *management user interface*. NOT
part of the first iteration....
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#use-cases>Use Cases
Below are the BASIC use-cases, that the AG Unified Push needs to *initially*
support.
- Enroll AeroGear-Push-User (based on identified roles)
- Remove AeroGear-Push-User
- Developer can register mobile App (for different Push Networks, e.g.
Apple, Android)
- Developer can unregister mobile App (for different Push Networks, e.g.
Apple, Android)
- User registers his phone with the backend (Device Token + APP-ID are
send to the backend)
- User unregisters his phone with the backend (e.g. app got deinstalled,
user deleted etc)
- User receives Push Messages (handled by the native OS, once accepted
to receive messages)
- Send push messages, done by a *user* or a *developer*
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#enroll>Enroll
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'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)
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-registered-use...
registered User
It should be possible to remove Users (app users). That can me their
account is erased or their device tokes are removed....
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#add-mobile-app>Add
mobile app
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)
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-mobile-app>...
mobile app
A registered *Developer* should be able to remove the apps from the server.
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#device-registration&g...
Registration
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.
*Note: On iOS the user as to agree to receive push messages*
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#remove-registered-dev...
registered Device
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...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#receives-push-message...
Push Messages
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.
*Note: On iOS the user as to agree to receive push messages*
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#send-push-messages>...
push messages<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#broadcast...
Broadcast
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 "AeroGear-App1" is only able to broadcast messages to that
particular app. He is *NOT* able to send a message to "AeroGear-App2"...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#filtered-messaging>...
messaging
Sending message to a specific user.... We need a DSL to filter users
etc.... This will be done later...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#in-app-messaging>I...
messaging
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...
<https://gist.github.com/matzew/7475652fa3b0cbb11c1c#api-access>API access
*Initial* focus is that the above functionality is *ONLY* accessable via
RESTful/HTTP APIs!
Later we will have a few more SDKs:
- Client APIs (for Android, iOS)
- Server APIs (send a push message out of your JavaEE app, without
submitting (manually) the HTTP calls)
Cheers!
Matthias
[1] https://gist.github.com/matzew/7475652fa3b0cbb11c1c
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:31 a.m.
Great info here Matthias, I'd like to test these scenarios with PicketLink. And
thinking aloud here what about scenarios like:
- Admin can disable push notifications to devices (simple as is at first glance initially)
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Tuesday, March 12, 2013 at 7:50 AM, Matthias Wessendorf wrote:
Hi,
after two weeks of prototyping and evaluating, I started the design phase of the AG
Unified Push Server.
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...
(COPY AND PAST FROM GIST):
AG Unified Push - Use Cases
Right now there are the following roles:
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)
User: Install an AG-App on his phone
Admin needed? yes, once we have a management user interface. NOT part of the first
iteration....
Use Cases
Below are the BASIC use-cases, that the AG Unified Push needs to initially support.
Enroll AeroGear-Push-User (based on identified roles)
Remove AeroGear-Push-User
Developer can register mobile App (for different Push Networks, e.g. Apple, Android)
Developer can unregister mobile App (for different Push Networks, e.g. Apple, Android)
User registers his phone with the backend (Device Token + APP-ID are send to the
backend)
User unregisters his phone with the backend (e.g. app got deinstalled, user deleted etc)
User receives Push Messages (handled by the native OS, once accepted to receive
messages)
Send push messages, done by a user or a developer
Enroll
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'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)
Remove registered User
It should be possible to remove Users (app users). That can me their account is erased or
their device tokes are removed....
Add mobile app
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)
Remove mobile app
A registered Developer should be able to remove the apps from the server.
Device Registration
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.
Note: On iOS the user as to agree to receive push messages
Remove registered Device
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...
Receives Push Messages
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.
Note: On iOS the user as to agree to receive push messages
Send push messages
Broadcast
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 "AeroGear-App1" is only
able to broadcast messages to that particular app. He is NOT able to send a message to
"AeroGear-App2"...
Filtered messaging
Sending message to a specific user.... We need a DSL to filter users etc.... This will be
done later...
In-APP messaging
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...
API access
Initial focus is that the above functionality is ONLY accessable via RESTful/HTTP APIs!
Later we will have a few more SDKs:
Client APIs (for Android, iOS)
Server APIs (send a push message out of your JavaEE app, without submitting (manually)
the HTTP calls)
Cheers!
Matthias
[1] https://gist.github.com/matzew/7475652fa3b0cbb11c1c
--
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 (mailto:aerogear-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/aerogear-dev
5:15 a.m.
Hi,
I have updated the gist to reflect Bruno's use-case. I also did a little
differentiation on "push apps" and "mobile app"
TL;DR:
Push App: my backend that sends messages to several mobile apps, on a
device (think: twitter backend)
Mobile App: an iOS/android version of the mobile view (think: twitter-iOS)
MobileInstance: a real installed version of the iOS version (think:
Matthias has the twitter-iOS app installed)
The BASIC domain model for the "application abstraction", is covered in
here:
https://gist.github.com/matzew/3e7e6218d6cea94f65ad
-Matthias
On Wed, Mar 13, 2013 at 8:31 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Great info here Matthias, I'd like to test these scenarios with
PicketLink. And thinking aloud here what about scenarios like:
- Admin can disable push notifications to devices (simple as is at first
glance initially)
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Tuesday, March 12, 2013 at 7:50 AM, Matthias Wessendorf wrote:
> Hi,
>
> after two weeks of prototyping and evaluating, I started the design
phase of the AG Unified Push Server.
>
> 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...
>
> (COPY AND PAST FROM GIST):
>
> AG Unified Push - Use Cases
>
> Right now there are the following roles:
>
> 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)
> User: Install an AG-App on his phone
> Admin needed? yes, once we have a management user interface. NOT part of
the first iteration....
>
> Use Cases
>
> Below are the BASIC use-cases, that the AG Unified Push needs to
initially support.
>
> Enroll AeroGear-Push-User (based on identified roles)
> Remove AeroGear-Push-User
> Developer can register mobile App (for different Push Networks, e.g.
Apple, Android)
> Developer can unregister mobile App (for different Push Networks, e.g.
Apple, Android)
> User registers his phone with the backend (Device Token + APP-ID are
send to the backend)
> User unregisters his phone with the backend (e.g. app got deinstalled,
user deleted etc)
> User receives Push Messages (handled by the native OS, once accepted to
receive messages)
> Send push messages, done by a user or a developer
>
> Enroll
>
> 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'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)
>
> Remove registered User
>
> It should be possible to remove Users (app users). That can me their
account is erased or their device tokes are removed....
>
> Add mobile app
>
> 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)
>
> Remove mobile app
>
> A registered Developer should be able to remove the apps from the server.
>
> Device Registration
>
> 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.
>
>
> Note: On iOS the user as to agree to receive push messages
>
> Remove registered Device
>
> 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...
>
> Receives Push Messages
>
> 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.
>
>
> Note: On iOS the user as to agree to receive push messages
>
> Send push messages
> Broadcast
>
> 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 "AeroGear-App1" is only able to broadcast messages to that particular
app. He is NOT able to send a message to "AeroGear-App2"...
>
> Filtered messaging
>
> Sending message to a specific user.... We need a DSL to filter users
etc.... This will be done later...
>
> In-APP messaging
>
> 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...
>
> API access
>
> Initial focus is that the above functionality is ONLY accessable via
RESTful/HTTP APIs!
>
>
> Later we will have a few more SDKs:
>
> Client APIs (for Android, iOS)
> Server APIs (send a push message out of your JavaEE app, without
submitting (manually) the HTTP calls)
>
>
>
>
>
>
>
>
>
>
>
>
>
> Cheers!
> Matthias
>
> [1] https://gist.github.com/matzew/7475652fa3b0cbb11c1c
> --
> 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 (mailto:aerogear-dev@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
8:28 a.m.
Some more APIs, for some basic (initial) functionality:
https://gist.github.com/matzew/c5fbc23bc97dfead46e1
User/Dev enrollment can be addressed by (hopefully) reusing the ag-security.
On Wed, Mar 13, 2013 at 11:15 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Hi,
I have updated the gist to reflect Bruno's use-case. I also did a little
differentiation on "push apps" and "mobile app"
TL;DR:
Push App: my backend that sends messages to several mobile apps, on a
device (think: twitter backend)
Mobile App: an iOS/android version of the mobile view (think: twitter-iOS)
MobileInstance: a real installed version of the iOS version (think:
Matthias has the twitter-iOS app installed)
The BASIC domain model for the "application abstraction", is covered in
here:
https://gist.github.com/matzew/3e7e6218d6cea94f65ad
-Matthias
On Wed, Mar 13, 2013 at 8:31 AM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
> Great info here Matthias, I'd like to test these scenarios with
> PicketLink. And thinking aloud here what about scenarios like:
>
> - Admin can disable push notifications to devices (simple as is at first
> glance initially)
>
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
>
>
> On Tuesday, March 12, 2013 at 7:50 AM, Matthias Wessendorf wrote:
>
> > Hi,
> >
> > after two weeks of prototyping and evaluating, I started the design
> phase of the AG Unified Push Server.
> >
> > 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...
> >
> > (COPY AND PAST FROM GIST):
> >
> > AG Unified Push - Use Cases
> >
> > Right now there are the following roles:
> >
> > 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)
> > User: Install an AG-App on his phone
> > Admin needed? yes, once we have a management user interface. NOT part
> of the first iteration....
> >
> > Use Cases
> >
> > Below are the BASIC use-cases, that the AG Unified Push needs to
> initially support.
> >
> > Enroll AeroGear-Push-User (based on identified roles)
> > Remove AeroGear-Push-User
> > Developer can register mobile App (for different Push Networks, e.g.
> Apple, Android)
> > Developer can unregister mobile App (for different Push Networks, e.g.
> Apple, Android)
> > User registers his phone with the backend (Device Token + APP-ID are
> send to the backend)
> > User unregisters his phone with the backend (e.g. app got deinstalled,
> user deleted etc)
> > User receives Push Messages (handled by the native OS, once accepted to
> receive messages)
> > Send push messages, done by a user or a developer
> >
> > Enroll
> >
> > 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'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)
> >
> > Remove registered User
> >
> > It should be possible to remove Users (app users). That can me their
> account is erased or their device tokes are removed....
> >
> > Add mobile app
> >
> > 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)
> >
> > Remove mobile app
> >
> > A registered Developer should be able to remove the apps from the
> server.
> >
> > Device Registration
> >
> > 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.
> >
> >
> > Note: On iOS the user as to agree to receive push messages
> >
> > Remove registered Device
> >
> > 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...
> >
> > Receives Push Messages
> >
> > 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.
> >
> >
> > Note: On iOS the user as to agree to receive push messages
> >
> > Send push messages
> > Broadcast
> >
> > 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 "AeroGear-App1" is only able to broadcast messages to that
> particular app. He is NOT able to send a message to "AeroGear-App2"...
> >
> > Filtered messaging
> >
> > Sending message to a specific user.... We need a DSL to filter users
> etc.... This will be done later...
> >
> > In-APP messaging
> >
> > 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...
> >
> > API access
> >
> > Initial focus is that the above functionality is ONLY accessable via
> RESTful/HTTP APIs!
> >
> >
> > Later we will have a few more SDKs:
> >
> > Client APIs (for Android, iOS)
> > Server APIs (send a push message out of your JavaEE app, without
> submitting (manually) the HTTP calls)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Cheers!
> > Matthias
> >
> > [1] https://gist.github.com/matzew/7475652fa3b0cbb11c1c
> > --
> > 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 (mailto:aerogear-dev@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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8:43 a.m.
FYI - the APIs are here:
https://github.com/matzew/ag-unified-push-api
NEXT: impl for testing + REST API endpoints
On Wed, Mar 13, 2013 at 2:28 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Some more APIs, for some basic (initial) functionality:
https://gist.github.com/matzew/c5fbc23bc97dfead46e1
User/Dev enrollment can be addressed by (hopefully) reusing the
ag-security.
On Wed, Mar 13, 2013 at 11:15 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> Hi,
>
> I have updated the gist to reflect Bruno's use-case. I also did a little
> differentiation on "push apps" and "mobile app"
>
> TL;DR:
> Push App: my backend that sends messages to several mobile apps, on a
> device (think: twitter backend)
> Mobile App: an iOS/android version of the mobile view (think:
> twitter-iOS)
> MobileInstance: a real installed version of the iOS version (think:
> Matthias has the twitter-iOS app installed)
>
> The BASIC domain model for the "application abstraction", is covered in
> here:
>
> https://gist.github.com/matzew/3e7e6218d6cea94f65ad
>
>
>
> -Matthias
>
>
> On Wed, Mar 13, 2013 at 8:31 AM, Bruno Oliveira <bruno(a)abstractj.org>wrote:
>
>> Great info here Matthias, I'd like to test these scenarios with
>> PicketLink. And thinking aloud here what about scenarios like:
>>
>> - Admin can disable push notifications to devices (simple as is at first
>> glance initially)
>>
>>
>> --
>> "The measure of a man is what he does with power" - Plato
>> -
>> @abstractj
>> -
>> Volenti Nihil Difficile
>>
>>
>>
>> On Tuesday, March 12, 2013 at 7:50 AM, Matthias Wessendorf wrote:
>>
>> > Hi,
>> >
>> > after two weeks of prototyping and evaluating, I started the design
>> phase of the AG Unified Push Server.
>> >
>> > 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...
>> >
>> > (COPY AND PAST FROM GIST):
>> >
>> > AG Unified Push - Use Cases
>> >
>> > Right now there are the following roles:
>> >
>> > 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)
>> > User: Install an AG-App on his phone
>> > Admin needed? yes, once we have a management user interface. NOT part
>> of the first iteration....
>> >
>> > Use Cases
>> >
>> > Below are the BASIC use-cases, that the AG Unified Push needs to
>> initially support.
>> >
>> > Enroll AeroGear-Push-User (based on identified roles)
>> > Remove AeroGear-Push-User
>> > Developer can register mobile App (for different Push Networks, e.g.
>> Apple, Android)
>> > Developer can unregister mobile App (for different Push Networks, e.g.
>> Apple, Android)
>> > User registers his phone with the backend (Device Token + APP-ID are
>> send to the backend)
>> > User unregisters his phone with the backend (e.g. app got deinstalled,
>> user deleted etc)
>> > User receives Push Messages (handled by the native OS, once accepted
>> to receive messages)
>> > Send push messages, done by a user or a developer
>> >
>> > Enroll
>> >
>> > 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'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)
>> >
>> > Remove registered User
>> >
>> > It should be possible to remove Users (app users). That can me their
>> account is erased or their device tokes are removed....
>> >
>> > Add mobile app
>> >
>> > 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)
>> >
>> > Remove mobile app
>> >
>> > A registered Developer should be able to remove the apps from the
>> server.
>> >
>> > Device Registration
>> >
>> > 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.
>> >
>> >
>> > Note: On iOS the user as to agree to receive push messages
>> >
>> > Remove registered Device
>> >
>> > 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...
>> >
>> > Receives Push Messages
>> >
>> > 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.
>> >
>> >
>> > Note: On iOS the user as to agree to receive push messages
>> >
>> > Send push messages
>> > Broadcast
>> >
>> > 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 "AeroGear-App1" is only able to broadcast messages to
that
>> particular app. He is NOT able to send a message to "AeroGear-App2"...
>> >
>> > Filtered messaging
>> >
>> > Sending message to a specific user.... We need a DSL to filter users
>> etc.... This will be done later...
>> >
>> > In-APP messaging
>> >
>> > 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...
>> >
>> > API access
>> >
>> > Initial focus is that the above functionality is ONLY accessable via
>> RESTful/HTTP APIs!
>> >
>> >
>> > Later we will have a few more SDKs:
>> >
>> > Client APIs (for Android, iOS)
>> > Server APIs (send a push message out of your JavaEE app, without
>> submitting (manually) the HTTP calls)
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Cheers!
>> > Matthias
>> >
>> > [1] https://gist.github.com/matzew/7475652fa3b0cbb11c1c
>> > --
>> > 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 (mailto:aerogear-dev@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
>
--
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
11:58 a.m.
On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org> wrote:
ome more APIs, for some basic (initial) functionality:
https://gist.github.com/matzew/c5fbc23bc97dfead46e1
I like the current form, but I'm sure we'll get asked about more OO(ish) APIs,
like device.send(Message) - is this on the plans?
User/Dev enrollment can be addressed by (hopefully) reusing the
ag-security.
+1
-- qmx
4:06 p.m.
I think this is look really good!
Here some thoughts, and/or possible additional use-cases
* How do we want to handle multiple devices for one user?
* How do we want to handle the other side of unified push (non-native)?
** Might just not be there yet, but want to make sure we're still thinking
the same thing :-)
** Would there be an additional abstraction above this for that?
* I'm assuming there is no good way for apps to notify you when they are
uninstalled?
** As a way of removing clutter in our tables.
* Push filtering - I would think IDM would be very good here.
** Sending to roles, groups, etc...
** When we store the device and app info what sub-system are you thinking?
*** I know you were using mongo for some of the prototyping
*** Would be possible to abstract to the IDM?
On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org> wrote:
> ome more APIs, for some basic (initial) functionality:
>
> https://gist.github.com/matzew/c5fbc23bc97dfead46e1
I like the current form, but I'm sure we'll get asked about more OO(ish)
APIs, like device.send(Message) - is this on the plans?
> User/Dev enrollment can be addressed by (hopefully) reusing the
ag-security.
+1
-- qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
blog: http://in.relation.to/Bloggers/Jay
5:03 p.m.
On Wed, Mar 13, 2013 at 10:06 PM, tech4j(a)gmail.com <tech4j(a)gmail.com> wrote:
I think this is look really good!
Here some thoughts, and/or possible additional use-cases
* How do we want to handle multiple devices for one user?
Instance of 'MobileApplicationInstance'; each device has (per app) a
different token;
What the apps do themselves, with multiple installs is something different.
Twitter, for instance, sends the push-messages to EVERY device - but that's
app specific sync
(yes, i wish there was something like IMAP, for twitter)
* How do we want to handle the other side of unified push (non-native)?
** Might just not be there yet, but want to make sure we're still thinking
the same thing :-)
** Would there be an additional abstraction above this for that?
some sub type of 'MobileApplication' can/will cover that "mobile web"
(JS
client) side:
https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o...
* I'm assuming there is no good way for apps to notify you when they are
uninstalled?
** As a way of removing clutter in our tables.
In apple land these are invalid tokens (see
https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoo...
)
So, on a scheduled base they can be remove;
Google has similar API (on their MulticastResult (returned by the sender))
* Push filtering - I would think IDM would be very good here.
** Sending to roles, groups, etc...
have different users (==roles), but not spec'd out
** When we store the device and app info what sub-system are you
thinking?
*** I know you were using mongo for some of the prototyping
*** Would be possible to abstract to the IDM?
yes, it should be possible (desirable) to use IDM - but does not really
matter
Thanks for the feedback!!!
-Matthias
On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>
> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
> > ome more APIs, for some basic (initial) functionality:
> >
> > https://gist.github.com/matzew/c5fbc23bc97dfead46e1
>
> I like the current form, but I'm sure we'll get asked about more OO(ish)
> APIs, like device.send(Message) - is this on the plans?
>
> > User/Dev enrollment can be addressed by (hopefully) reusing the
> ag-security.
>
> +1
>
> -- qmx
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
blog: http://in.relation.to/Bloggers/Jay
_______________________________________________
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
5:04 a.m.
My UNIT test looks (currently) like:
https://gist.github.com/matzew/3d7f9915afd8f6705da5
-M
On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Wed, Mar 13, 2013 at 10:06 PM, tech4j(a)gmail.com <tech4j(a)gmail.com>wrote:
> I think this is look really good!
>
> Here some thoughts, and/or possible additional use-cases
>
> * How do we want to handle multiple devices for one user?
>
Instance of 'MobileApplicationInstance'; each device has (per app) a
different token;
What the apps do themselves, with multiple installs is something different.
Twitter, for instance, sends the push-messages to EVERY device - but
that's app specific sync
(yes, i wish there was something like IMAP, for twitter)
>
> * How do we want to handle the other side of unified push (non-native)?
> ** Might just not be there yet, but want to make sure we're still
> thinking the same thing :-)
> ** Would there be an additional abstraction above this for that?
>
some sub type of 'MobileApplication' can/will cover that "mobile web"
(JS
client) side:
https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o...
>
> * I'm assuming there is no good way for apps to notify you when they are
> uninstalled?
> ** As a way of removing clutter in our tables.
>
In apple land these are invalid tokens (see
https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoo...
)
So, on a scheduled base they can be remove;
Google has similar API (on their MulticastResult (returned by the sender))
>
> * Push filtering - I would think IDM would be very good here.
> ** Sending to roles, groups, etc...
>
have different users (==roles), but not spec'd out
> ** When we store the device and app info what sub-system are you thinking?
> *** I know you were using mongo for some of the prototyping
> *** Would be possible to abstract to the IDM?
>
yes, it should be possible (desirable) to use IDM - but does not really
matter
Thanks for the feedback!!!
-Matthias
>
> On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>
>>
>> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>
>> > ome more APIs, for some basic (initial) functionality:
>> >
>> > https://gist.github.com/matzew/c5fbc23bc97dfead46e1
>>
>> I like the current form, but I'm sure we'll get asked about more OO(ish)
>> APIs, like device.send(Message) - is this on the plans?
>>
>> > User/Dev enrollment can be addressed by (hopefully) reusing the
>> ag-security.
>>
>> +1
>>
>> -- qmx
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> blog: http://in.relation.to/Bloggers/Jay
>
> _______________________________________________
> 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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9:41 a.m.
Pushed FIRST/TEST impl + actually test case.....
https://github.com/matzew/ag-unified-push-api
YEs.... I have 'xxx'd out the KEY and certs :)
On Thu, Mar 14, 2013 at 11:04 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
My UNIT test looks (currently) like:
https://gist.github.com/matzew/3d7f9915afd8f6705da5
-M
On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>
> On Wed, Mar 13, 2013 at 10:06 PM, tech4j(a)gmail.com <tech4j(a)gmail.com>wrote:
>
>> I think this is look really good!
>>
>> Here some thoughts, and/or possible additional use-cases
>>
>> * How do we want to handle multiple devices for one user?
>>
>
> Instance of 'MobileApplicationInstance'; each device has (per app) a
> different token;
> What the apps do themselves, with multiple installs is something
> different.
>
> Twitter, for instance, sends the push-messages to EVERY device - but
> that's app specific sync
> (yes, i wish there was something like IMAP, for twitter)
>
>
>
>>
>> * How do we want to handle the other side of unified push (non-native)?
>> ** Might just not be there yet, but want to make sure we're still
>> thinking the same thing :-)
>> ** Would there be an additional abstraction above this for that?
>>
>
> some sub type of 'MobileApplication' can/will cover that "mobile
web" (JS
> client) side:
>
>
https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o...
>
>
>>
>> * I'm assuming there is no good way for apps to notify you when they are
>> uninstalled?
>> ** As a way of removing clutter in our tables.
>>
>
> In apple land these are invalid tokens (see
>
https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoo...
> )
> So, on a scheduled base they can be remove;
>
> Google has similar API (on their MulticastResult (returned by the sender))
>
>
>>
>> * Push filtering - I would think IDM would be very good here.
>> ** Sending to roles, groups, etc...
>>
>
> have different users (==roles), but not spec'd out
>
>
>> ** When we store the device and app info what sub-system are you
>> thinking?
>> *** I know you were using mongo for some of the prototyping
>> *** Would be possible to abstract to the IDM?
>>
>
> yes, it should be possible (desirable) to use IDM - but does not really
> matter
>
>
> Thanks for the feedback!!!
>
> -Matthias
>
>
>
>>
>> On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>>
>>>
>>> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>>
>>> > ome more APIs, for some basic (initial) functionality:
>>> >
>>> > https://gist.github.com/matzew/c5fbc23bc97dfead46e1
>>>
>>> I like the current form, but I'm sure we'll get asked about more
>>> OO(ish) APIs, like device.send(Message) - is this on the plans?
>>>
>>> > User/Dev enrollment can be addressed by (hopefully) reusing the
>>> ag-security.
>>>
>>> +1
>>>
>>> -- qmx
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> blog: http://in.relation.to/Bloggers/Jay
>>
>> _______________________________________________
>> 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
>
--
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
12:58 p.m.
here is, including device registration:
https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/o...
All hammered in java... since this is a test - most of the code will be
executed, when interacting with HTTP endpoints of the thing;
Yes, there is no JS application in the test - but we do have an abstraction
interface for it:
https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o...
Connected? Since only "online" JS clients are receiving message - there no
real "push to device" for the JS world...
-Matthias
On Thu, Mar 14, 2013 at 3:41 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Pushed FIRST/TEST impl + actually test case.....
https://github.com/matzew/ag-unified-push-api
YEs.... I have 'xxx'd out the KEY and certs :)
On Thu, Mar 14, 2013 at 11:04 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> My UNIT test looks (currently) like:
>
> https://gist.github.com/matzew/3d7f9915afd8f6705da5
>
>
>
> -M
>
>
>
>
> On Wed, Mar 13, 2013 at 11:03 PM, Matthias Wessendorf
<matzew(a)apache.org>wrote:
>
>>
>>
>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j(a)gmail.com
<tech4j(a)gmail.com>wrote:
>>
>>> I think this is look really good!
>>>
>>> Here some thoughts, and/or possible additional use-cases
>>>
>>> * How do we want to handle multiple devices for one user?
>>>
>>
>> Instance of 'MobileApplicationInstance'; each device has (per app) a
>> different token;
>> What the apps do themselves, with multiple installs is something
>> different.
>>
>> Twitter, for instance, sends the push-messages to EVERY device - but
>> that's app specific sync
>> (yes, i wish there was something like IMAP, for twitter)
>>
>>
>>
>>>
>>> * How do we want to handle the other side of unified push (non-native)?
>>> ** Might just not be there yet, but want to make sure we're still
>>> thinking the same thing :-)
>>> ** Would there be an additional abstraction above this for that?
>>>
>>
>> some sub type of 'MobileApplication' can/will cover that "mobile
web"
>> (JS client) side:
>>
>>
https://github.com/matzew/ag-unified-push-api/blob/master/src/main/java/o...
>>
>>
>>>
>>> * I'm assuming there is no good way for apps to notify you when they
>>> are uninstalled?
>>> ** As a way of removing clutter in our tables.
>>>
>>
>> In apple land these are invalid tokens (see
>>
https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoo...
>> )
>> So, on a scheduled base they can be remove;
>>
>> Google has similar API (on their MulticastResult (returned by the
>> sender))
>>
>>
>>>
>>> * Push filtering - I would think IDM would be very good here.
>>> ** Sending to roles, groups, etc...
>>>
>>
>> have different users (==roles), but not spec'd out
>>
>>
>>> ** When we store the device and app info what sub-system are you
>>> thinking?
>>> *** I know you were using mongo for some of the prototyping
>>> *** Would be possible to abstract to the IDM?
>>>
>>
>> yes, it should be possible (desirable) to use IDM - but does not really
>> matter
>>
>>
>> Thanks for the feedback!!!
>>
>> -Matthias
>>
>>
>>
>>>
>>> On Wed, Mar 13, 2013 at 12:58 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>>>
>>>>
>>>> On 13/03/2013, at 10:28, Matthias Wessendorf <matzew(a)apache.org>
>>>> wrote:
>>>>
>>>> > ome more APIs, for some basic (initial) functionality:
>>>> >
>>>> > https://gist.github.com/matzew/c5fbc23bc97dfead46e1
>>>>
>>>> I like the current form, but I'm sure we'll get asked about more
>>>> OO(ish) APIs, like device.send(Message) - is this on the plans?
>>>>
>>>> > User/Dev enrollment can be addressed by (hopefully) reusing the
>>>> ag-security.
>>>>
>>>> +1
>>>>
>>>> -- qmx
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> blog: http://in.relation.to/Bloggers/Jay
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> 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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11:35 a.m.
On 13/03/2013, at 07:15, Matthias Wessendorf <matzew(a)apache.org> wrote:
The BASIC domain model for the "application abstraction",
is covered in here:
https://gist.github.com/matzew/3e7e6218d6cea94f65ad
I like this!
My only comment would be to remove the setter for name and description, and let it be a
concrete class concern
-- qmx
11:37 a.m.
On Wed, Mar 13, 2013 at 5:35 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On 13/03/2013, at 07:15, Matthias Wessendorf <matzew(a)apache.org> wrote:
> The BASIC domain model for the "application abstraction", is covered in
here:
>
> https://gist.github.com/matzew/3e7e6218d6cea94f65ad
I like this!
My only comment would be to remove the setter for name and description,
and let it be a concrete class concern
Oh, yeah :) just scratiching the model :) (instead of "class diagram") :)
-- qmx
_______________________________________________
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
11:43 a.m.
On Wed, Mar 13, 2013 at 5:35 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On 13/03/2013, at 07:15, Matthias Wessendorf <matzew(a)apache.org> wrote:
> The BASIC domain model for the "application abstraction", is covered in
here:
>
> https://gist.github.com/matzew/3e7e6218d6cea94f65ad
I like this!
My only comment would be to remove the setter for name and description,
and let it be a concrete class concern
I think, I will convert them into concrete clazzes :)
-- qmx
_______________________________________________
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
4256
days inactive
4258
days old
13 comments
4 participants
participants (4)
-
Bruno Oliveira -
Douglas Campos -
Matthias Wessendorf -
tech4j＠gmail.com