[aerogear-dev] Next steps for Push (was: Re: AeroGear Unified Push - Abstraction layer for "push enabled apps" (was: Re: [AG Push] BASIC (and INITAL) use cases of the Unified Push Server))

Fri Mar 15 09:17:24 EDT 2013

On Fri, Mar 15, 2013 at 2:11 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
> Great thing to start writing the server bits with vertx :
>
> I presume you will write endpoints for register / unregister and
> getPushApplications functions ?

/send
/registerApp
/register blah

>
> Do we have to discuss the format of REST services/messages or is it just a
> JSONfied version of the interfaces you already have ?

some formal discussion on the API follows :-)

>
> Vertx beeing polyglot,  I assume you will write it in Groovy ;)

nah - perl

>
>
> Seb
>
>
> On Fri, Mar 15, 2013 at 1:55 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>>
>> hijacking threads - FTW
>>
>> So... that feedback was great... and I am still hoping for more input
>> on the OTHER thread...
>>
>>
>> So... here is my proposal: I wait for today/monday for more feedback
>> and I will THAN move all the ideas into a OVERALL doc - which will
>> endup on the homepage;
>>
>> Also, I'll start implementing that SERVER, using vert.x - where the
>> service/server itself is accessible via HTTP/REST (only)
>>
>> Thoughts?
>>
>>
>> On Fri, Mar 15, 2013 at 1:47 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>> >
>> >
>> >
>> > On Fri, Mar 15, 2013 at 1:28 PM, tech4j at gmail.com <tech4j at gmail.com>
>> > wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Fri, Mar 15, 2013 at 8:25 AM, Matthias Wessendorf
>> >> <matzew at apache.org> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Mar 15, 2013 at 1:15 PM, tech4j at gmail.com <tech4j at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> A few small comments, because I think this is looking pretty good.
>> >>>>
>> >>>> * At first glance I like the idea of having it be a registry instead
>> >>>> of a manager.  In some ways that makes it more obvious this a logical
>> >>>> construct.
>> >>>>
>> >>>> * Another use case:  "Other services inside of JBoss could use the
>> >>>> push manager/registry, for example the admin console, Errai, drools, etc..."
>> >>>> ** I.e. not just for end user apps
>> >>>
>> >>>
>> >>>
>> >>> I think that's what I tried to address with this statement: "We want
>> >>> that any (JBoss/AeroGear powered) mobile application, that is backed by
>> >>> JBoss technology, is able to easily work with push messages. For a JBoss
>> >>> "backend application" it should be as simple as possible, to send messages
>> >>> to its different mobile clients"
>> >>>
>> >>> ==> should not be tied to a specific backend; For instance a JSF
>> >>> managed bean you use the "Sender" as well - to push out messages to 'its'
>> >>> configured mobile apps (on the registration)
>> >>
>> >>
>> >> ok, then yes, same page
>> >>
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> * The non-native push (JS, "connected" apps, etc...) imo would/should
>> >>>> be separate and part of AeroGear proper.  I think having both functions in
>> >>>> this one shared service would make it too complex, and hard to cover other
>> >>>> groups use-cases.  As I see it for AeroGear - we receive a msg/event/trigger
>> >>>> that we want to send to clients.  The API allows developers to say "send msg
>> >>>> to x, y, z users/devices".  AeroGear checks for any apps that are
>> >>>> "connected" and sends a non-native push msg to those clients.  AeroGear then
>> >>>> determines who did not get a "connected" msg (that may be tricky), and uses
>> >>>> the API your defining to send those users native push msg.
>> >>>
>> >>>
>> >>> You mean breaking into two components?
>> >>> - native push
>> >>> - web based push
>> >>>
>> >>> and an overall API on top that 'aggregates'?
>> >>
>> >>
>> >> Yes, and yes :-)
>> >
>> >
>> >
>> > Ah - great!
>> >
>> > I think that is a great idea, since the "non-native" web-push is really
>> > a different case, and there are lot's of different impls - having that piece
>> > separated, makes it easier to actually implement the native push thing
>> >
>> >>
>> >>
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> ** The API would have a way to set only "connected", only native,
>> >>>> etc... as well.
>> >>>>
>> >>>> * In the future and maybe as a POC that this can work with
>> >>>> non-aerogear clients we could see about getting push messages setup with
>> >>>> Christos' JBoss admin app with this.  Not a priority, but an idea :-)
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Fri, Mar 15, 2013 at 6:56 AM, Matthias Wessendorf
>> >>>> <matzew at apache.org> wrote:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Fri, Mar 15, 2013 at 11:27 AM, Sebastien Blanc
>> >>>>> <scm.blanc at gmail.com> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Fri, Mar 15, 2013 at 10:58 AM, Matthias Wessendorf
>> >>>>>> <matzew at apache.org> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, Mar 15, 2013 at 10:48 AM, Sebastien Blanc
>> >>>>>>> <scm.blanc at gmail.com> wrote:
>> >>>>>>>>
>> >>>>>>>> Great Job,
>> >>>>>>>> see my comments inline.
>> >>>>>>>>
>> >>>>>>>> On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf
>> >>>>>>>> <matzew at apache.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>> As discussed on the earlier theard, we have some raw APIs...
>> >>>>>>>>> Below a little summary:
>> >>>>>>>>>
>> >>>>>>>>> We have a UnifiedPushManager(.java) defined, which is basically
>> >>>>>>>>> a registry for "push enabled" apps (PushApplication.java). Such a
>> >>>>>>>>> PushApplication is a logical construct on the backend which is
>> >>>>>>>>> allowed/enabled to send notifications to mobile clients. One example could
>> >>>>>>>>> be the "Twitter Backend" (e.g. for push notification on direct messages).
>> >>>>>>>>
>> >>>>>>>> As you said the manager is here more a registry than a manager in
>> >>>>>>>> the current state, maybe we should have a PushApplicationRegistry interface
>> >>>>>>>> which has as only responsibility to hold the register state,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Can you gist ?
>> >>>>>>
>> >>>>>>
>> >>>>>> Take a look at my fork
>> >>>>>> https://github.com/sebastienblanc/ag-unified-push-api/tree/registry ;)
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> the implementation of the registry will connect to the chosen
>> >>>>>>>> persistence unit (JPA/Mongo/Oracle ...).
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Not sure I really want to that - now :) I am (for first iteration)
>> >>>>>>> fine to have something running, instead of being that flexible and be able
>> >>>>>>> to go with any existing "data source" :-)
>> >>>>>>
>> >>>>>>
>> >>>>>> Well, for sure, for the first iteration we will provide a default
>> >>>>>> implementation.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> This way we could have a concrete implementation of the
>> >>>>>>>> UnifiedPushManager than can be used by different backend/customers (think
>> >>>>>>>> DRY) , they just have to inject the needed PushApplicationRegistry
>> >>>>>>>> implementation.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Not sure what exactly you mean - perhaps a gist / pseudo code is
>> >>>>>>> helpful here too ?
>> >>>>>>
>> >>>>>>
>> >>>>>> Again, my fork should help you understanding
>> >>>>>> https://github.com/sebastienblanc/ag-unified-push-api/tree/registry but
>> >>>>>> basically, it is the same as your code except I apply the delegate pattern.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> Now each of the PushApplication can have a few mobile
>> >>>>>>>>> applications, that receive those push messages (e.g. the offical Twitter iOS
>> >>>>>>>>> client and the offical Twitter Android client). These "mobile apps" are
>> >>>>>>>>> represented - on the server - with the MobileApplication.java class. Usually
>> >>>>>>>>> there is only one iOS app and one Android... BUT imagine the case of a
>> >>>>>>>>> "paid/premium app" versus a free app (e.g. something like TwitterPro-iOS and
>> >>>>>>>>> Twitter-free-iOS... NOTE: there is NOTHING like that, I just made these two
>> >>>>>>>>> apps up, to explain the concept).
>> >>>>>>>>>
>> >>>>>>>>> Of course there are several installations of the iOS(and
>> >>>>>>>>> Android...) app. Each installation is represented with
>> >>>>>>>>> theMobileApplicationInstance.java class. Each installation is registered by
>> >>>>>>>>> a "device registration service": The actual app on the device submits its
>> >>>>>>>>> token/regId (and some other infos) to a HTTP endpoint....
>> >>>>>>>>>
>> >>>>>>>>> Now the UnifiedPushManager(.java) is the central API to register
>> >>>>>>>>> PushApps and their mobile views, including (device)registration of
>> >>>>>>>>> installations (-> MobileApplication and MobileApplicationInstance).
>> >>>>>>>>>
>> >>>>>>>>> Any backend app, can now use the Sender API to actually send the
>> >>>>>>>>> message to these different devices/appications, from the UnifiedPushManager,
>> >>>>>>>>> assuming they have permission :-)
>> >>>>>>>>>
>> >>>>>>>>> A simple example is here (java code for registration AND
>> >>>>>>>>> sending); Note it's a Unit test.......:
>> >>>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/org/jboss/aerogear/push/UnifiedPushManagerTest.java#L41-L81
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Maybe the Sender interface should be an attribute of the
>> >>>>>>>> PushManager, the customer can set his Sender impl
>> >>>>>>>> (pushManager.setSender(...) )  and the UnifiedManager act as a facade for
>> >>>>>>>> the "sending" actions.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Hrm - you really think folks will write their own "Senders"? I
>> >>>>>>> think... if they want to add support for "Windows Mobile", they just have to
>> >>>>>>> extend the abstract MobileApplicationImpl and implement it's send() to talk
>> >>>>>>> to the Windows Push infrastrucuture
>> >>>>>>
>> >>>>>>
>> >>>>>> Again, we will provide a default sender implementation. But I seee
>> >>>>>> indedd issues, having a single senders for different platforms , hum, let me
>> >>>>>> think about this ;)
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> the Sender() is an aggregate of the different mobile Application's
>> >>>>> "send()" - it will enqueue the message for the different platforms
>> >>>>>
>> >>>>>
>> >>>>> thanks for the feedback - will check ur fork
>> >>>>>
>> >>>>>
>> >>>>> -M
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> PERHAPS... just using interfaces was confusing  - there will be
>> >>>>>>> concrete classes (first impl is in the TEST project (see other thread)), but
>> >>>>>>> the interfaces are a highlevel view of the "domain model"
>> >>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> So far, so good - but why this abstraction ????
>> >>>>>>>>>
>> >>>>>>>>> Goal: We want that any (JBoss/AeroGear powered) mobile
>> >>>>>>>>> application, that is backed by JBoss technology, is able to easily work with
>> >>>>>>>>> push messages. For a JBoss "backend application" it should be as simple as
>> >>>>>>>>> possible, to send messages to its different mobile clients
>> >>>>>>>>>
>> >>>>>>>>> Some Scenarios
>> >>>>>>>>>
>> >>>>>>>>> MyWarehouseInc-backend can send messages to different "customer"
>> >>>>>>>>> groups (e.g. discounts for only iOS (or only Android) users).
>> >>>>>>>>> MyInsuranceCorp-backend can send important "info messages" to
>> >>>>>>>>> diffenrent variants of its mobile Applications (e.g. to the
>> >>>>>>>>> MyInsuranceCustomer-APP (regardless of the OS) AND to the app for their own
>> >>>>>>>>> agents (MyInsuranceAgent-APP))
>> >>>>>>>>> MyPublishing-Company-backend sends updates to all of its apps
>> >>>>>>>>> (free and premium - regardless of the mobile OS). Advanced content is only
>> >>>>>>>>> push to the paying customers...
>> >>>>>>>>> A company has different backends (small apps for different
>> >>>>>>>>> tasks) - and these different backends could be able to reach all of the
>> >>>>>>>>> company's mobile apps
>> >>>>>>>>>
>> >>>>>>>>> So... the Sender somewhat acts as a broker (for accessable apps
>> >>>>>>>>> on the 'registry' UnifiedPushManager)...
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Maybe we should define some kind of "Application" Collection, as
>> >>>>>>>> smart/specific  Java Collection implementation to be able to create easily
>> >>>>>>>> groups of apps etc .. just a rough idea that needs to be cleaned up ;)
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Something like that would be neat, for more advanced queries /
>> >>>>>>> selection etc
>> >>>>>>
>> >>>>>>
>> >>>>>> We could have a (very) simple query language specific for Push
>> >>>>>> Apps, like hibernate, we could query by example. In my fork you will see an
>> >>>>>> extremely basic Query object ...
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Thanks for the feedback!
>> >>>>>>> -M
>> >>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> BTW... none!!!!!!! of the API names are final - happy to hear
>> >>>>>>>>> better names!!!
>> >>>>>>>>>
>> >>>>>>>>> Please provide feedback (here and on the other thread), for
>> >>>>>>>>> missing/wrong/good items.!
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Greetings,
>> >>>>>>>>> Matthias
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Thu, Mar 14, 2013 at 6:58 PM, Matthias Wessendorf
>> >>>>>>>>> <matzew at apache.org> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> here is, including device registration:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> https://github.com/matzew/ag-unified-push-api/blob/master/src/test/java/org/jboss/aerogear/push/UnifiedPushManagerTest.java#L41-L81
>> >>>>>>>>>>
>> >>>>>>>>>> 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/org/jboss/aerogear/push/application/ConnectedJavaScriptApplication.java
>> >>>>>>>>>>
>> >>>>>>>>>> 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 at 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 at 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 at apache.org> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j at gmail.com
>> >>>>>>>>>>>>> <tech4j at 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/org/jboss/aerogear/push/application/MobileApplication.java#L23
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> * 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/notnoop/apns/ApnsService.java#L161)
>> >>>>>>>>>>>>> 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 at qmx.me> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On 13/03/2013, at 10:28, Matthias Wessendorf
>> >>>>>>>>>>>>>>> <matzew at 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 at lists.jboss.org
>> >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>> blog: http://in.relation.to/Bloggers/Jay
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>>>>> aerogear-dev mailing list
>> >>>>>>>>>>>>>> aerogear-dev at 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
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>> Matthias Wessendorf
>> >>>>>>>>>
>> >>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>> >>>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>> >>>>>>>>> twitter: http://twitter.com/mwessendorf
>> >>>>>>>>> _______________________________________________
>> >>>>>>>>> aerogear-dev mailing list
>> >>>>>>>>> aerogear-dev at lists.jboss.org
>> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> _______________________________________________
>> >>>>>>>> aerogear-dev mailing list
>> >>>>>>>> aerogear-dev at 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 at lists.jboss.org
>> >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> aerogear-dev mailing list
>> >>>>>> aerogear-dev at 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 at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> blog: http://in.relation.to/Bloggers/Jay
>> >>>>
>> >>>> _______________________________________________
>> >>>> aerogear-dev mailing list
>> >>>> aerogear-dev at 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 at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> blog: http://in.relation.to/Bloggers/Jay
>> >>
>> >> _______________________________________________
>> >> aerogear-dev mailing list
>> >> aerogear-dev at 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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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