[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))
Sebastien Blanc
scm.blanc at gmail.com
Fri Mar 15 09:11:37 EDT 2013
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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130315/7d30ef2f/attachment-0001.html
More information about the aerogear-dev
mailing list