"CDI events" are a programming model (API) not an implementation. I don't
think the API would constrain scalability here, the thing that would constrain scalability
would be (as usual) around how the bus was implemented from the JVM to the phone (aka
IO).
On 18 Sep 2012, at 13:45, Burr Sutter wrote:
Would CDI events handle the scenario of 100K end-users (with unique
deviceIDs) receiving their push notifications? - I believe Apple allows for approximately
20 messages at a time - so pushes need to be queued and managed.
I will try to investigate more...just need to find enough time.
On Sep 18, 2012, at 1:33 AM, Matthias Wessendorf wrote:
> agreed,
>
> CDI events (similar like JMS events) are a good fit
>
> -M
>
> On Tue, Sep 18, 2012 at 3:26 AM, Marius Bogoevici <mariusb(a)redhat.com> wrote:
>> Off the top of my head (and I'm sure that this has been discussed within the
AG team extensively already), a CDI-driven push mechanism (that Java EE developers could
just hook in their apps) would be great.
>>
>> On 2012-09-17, at 8:01 PM, Jay Balunas <jbalunas(a)redhat.com> wrote:
>>
>>> Yes, push notifications is something we certainly have considered, but need
to get more concrete roadmaps in place. The most obvious use is extending messaging, and
CDI events, but data syncing is also valid.
>>>
>>> IMO - the biggest concern with push is setup, and frequency. These needs to
be considered and be an active option for developers. We also want to think about this as
a secondary priority to initial basic options imo.
>>>
>>> The concern about server-side coupling is valid, but we should be able to get
around that by defining the expected message formats and connections + the required config
options.
>>>
>>> ----- Original Message -----
>>>>
>>>> Hey team,
>>>>
>>>> So thinking a bit about the Android roadmap, and realizing that for
>>>> either the Android or the iOS libs to work well (i.e. without killing
>>>> the batteries of end-users' phones), we're going to need to do
push
>>>> integration.
>>>>
>>>> A quick recap - if we want to know when data on the backend has been
>>>> updated without a manual "refresh" button, we either have to 1)
poll
>>>> (which sucks, uses network resources, and doesn't work in the
>>>> background
>>>> on iOS devices) or 2) use push (for which there are specific APIs for
>>>> Android and iOS, and there are also "higher level" push
service
>>>> providers such as Urban Airship).
>>>>
>>>> Yes, polling can be used as a fallback, but for any serious
>>>> application
>>>> that needs live or background updates, push is the only way to go.
>>>> Yes,
>>>> this means another coupling point to "our" server (or at least
>>>> contract-compatible servers).
>>>>
>>>> Just wanting to make sure that this is on everyone's radar.
>>>>
>>>> Thoughts/comments?
>>>>
>>>> --Glen
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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