Great thing to start writing the server bits with vertx : I presume you will write endpoints for register / unregister and getPushApplications functions ?

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

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

Seb On Fri, Mar 15, 2013 at 1:55 PM, Matthias Wessendorf <matzew(a)apache.org&gt; 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(a)apache.org&gt; > wrote: > > > > > > > > On Fri, Mar 15, 2013 at 1:28 PM, tech4j(a)gmail.com <tech4j(a)gmail.com&gt; > > wrote: > >> > >> > >> > >> > >> On Fri, Mar 15, 2013 at 8:25 AM, Matthias Wessendorf > >> <matzew(a)apache.org&gt; wrote: > >>> > >>> > >>> > >>> On Fri, Mar 15, 2013 at 1:15 PM, tech4j(a)gmail.com <tech4j(a)gmail.com&gt; > >>> 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(a)apache.org&gt; wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Mar 15, 2013 at 11:27 AM, Sebastien Blanc > >>>>> <scm.blanc(a)gmail.com&gt; wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Mar 15, 2013 at 10:58 AM, Matthias Wessendorf > >>>>>> <matzew(a)apache.org&gt; wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Mar 15, 2013 at 10:48 AM, Sebastien Blanc > >>>>>>> <scm.blanc(a)gmail.com&gt; wrote: > >>>>>>>> > >>>>>>>> Great Job, > >>>>>>>> see my comments inline. > >>>>>>>> > >>>>>>>> On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf > >>>>>>>> <matzew(a)apache.org&gt; 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/o... > >>>>>>>> > >>>>>>>> > >>>>>>>> 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(a)apache.org&gt; wrote: > >>>>>>>>>> > >>>>>>>>>> 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&gt; 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&gt; 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&gt; wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Wed, Mar 13, 2013 at 10:06 PM, tech4j(a)gmail.com > >>>>>>>>>>>>> <tech4j(a)gmail.com&gt; 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&gt; wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 13/03/2013, at 10:28, Matthias Wessendorf > >>>>>>>>>>>>>>> <matzew(a)apache.org&gt; 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Matthias Wessendorf > >>>>>>>>> > >>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>>>>>>> sessions: http://www.slideshare.net/mwessendorf > >>>>>>>>> twitter: http://twitter.com/mwessendorf > >>>>>>>>> _______________________________________________ > >>>>>>>>> aerogear-dev mailing list > >>>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> aerogear-dev mailing list > >>>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Matthias Wessendorf > >>>>>>> > >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>>>>> sessions: http://www.slideshare.net/mwessendorf > >>>>>>> twitter: http://twitter.com/mwessendorf > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> aerogear-dev mailing list > >>>>>>> aerogear-dev(a)lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> aerogear-dev mailing list > >>>>>> aerogear-dev(a)lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> 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 > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> 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 > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > 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