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