On Fri, Mar 15, 2013 at 8:10 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Sebi,
I don't like that the Unified Push manager is the central entry point for:
-query/finding
-sending
-registration
+1 - The "native" push service should be simple and separate from some of
these functions.
However, I like the concept (name) of registration - let me rename my
```UnifiedPushManager```. It will be called ```PushApplicationRegistry```;
I like the concept of the```ApplicationQuery```, but that's IMO a layer on
top the pure send. At the end of the day, for the plain message delivery,
it does not matter why a token/device has been chosen. It only matters that
it was chosen, and it is about to receive a message.
The matching APIs - for now - are just pure model abstractions. However,
having something like the `ApplicationQuery` in mind is not bad - thanks
for the feedback
On Fri, Mar 15, 2013 at 11: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 the
>>>>> MobileApplicationInstance.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"
>>>
>>>
>>>>
>>>>>
<
https://gist.github.com/matzew/73d478a42c093e21a6b9#so-far-so-good---but-...
>>>>> 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
>>>>>
<
https://gist.github.com/matzew/73d478a42c093e21a6b9#some-scenarios>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
>
--
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