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>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>
wrote:
>
>
>
> On Fri, Mar 15, 2013 at 1:28 PM, tech4j(a)gmail.com <tech4j(a)gmail.com>
wrote:
>>
>>
>>
>>
>> On Fri, Mar 15, 2013 at 8:25 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>>
>>>
>>>
>>> On Fri, Mar 15, 2013 at 1:15 PM, tech4j(a)gmail.com <tech4j(a)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(a)apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 15, 2013 at 11:27 AM, Sebastien Blanc <
scm.blanc(a)gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 15, 2013 at 10:58 AM, Matthias Wessendorf <
matzew(a)apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 15, 2013 at 10:48 AM, Sebastien Blanc <
scm.blanc(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>> Great Job,
>>>>>>>> see my comments inline.
>>>>>>>>
>>>>>>>> On Fri, Mar 15, 2013 at 10:07 AM, Matthias Wessendorf
<
matzew(a)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/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> 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> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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