[aerogear-dev] [RFC] future Roadmap for Unified Push Server

Thu Jul 9 05:28:57 EDT 2015

On Thu, Jul 9, 2015 at 10:42 AM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> Looks good !
>
> Some comments inline
>
> On Tue, Jul 7, 2015 at 11:51 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi team,
>>
>> as we are moving forward w/ the releases, and we are close to have our
>> 1.1.0.Final, I started to think about a proposal for a near-term future
>> roadmap, and I'd like to get feedback, comments (or tomatos) on it.
>> <https://gist.github.com/matzew/35c3e3b12f78d2ed55f5#ups-11x-julyaugust>UPS
>> 1.1.x (July/August)
>>
>>    - 1.1.0 -> very soon
>>    - 1.1.x -> perhaps some needed bug fixes/improvements, in a short
>>    interval :-)
>>
>>
>> <https://gist.github.com/matzew/35c3e3b12f78d2ed55f5#ups-120-septemberoctober>UPS
>> 1.2.0 (September/October)
>>
>> We have a release version
>> <https://issues.jboss.org/browse/AGPUSH/fixforversion/12327301> in JIRA
>> already.
>>
>> *Key features*
>>
>>    - Keycloak isolation
>>    - GCM 3 support (client and server)
>>
>> For server, does that mean using their xmpp connection instead of http ?
>

GMC 3.0 supports both, actually - but there is a ticket nested for us, to
move over to their XMPP based connection approach.

>
>>    - Improved docker support (e.g. tests/test suite -> Hopefully Travis
>>    supports 'docker run' by than ;-))
>>
>> One could think that going back to JPA annotations is a key feature as
>> well ;-)
>>
>> <https://gist.github.com/matzew/35c3e3b12f78d2ed55f5#ups-12x-or-even-130-december-2015>UPS
>> 1.2.x (or even 1.3.0) (December 2015)
>>
>> There is no concrete release version for this, but we have a larger
>> ups-future
>> <https://issues.jboss.org/browse/AGPUSH/fixforversion/12321884> version
>> in JIRA. The ups-future version/label has a few interesting things, that we
>> may have to do right after 1.2.0
>>
>> *Key features*
>>
>>    - APNs goes HTTP2 (a must)
>>    - Quiete time for push (aka timezone awareness of devices)
>>    - Scheduled pushes
>>    - Proxy server support
>>
>> Maybe we could consider some new features around metrics/analytics : I'm
> thinking of A/B testing for instance
>

Good point - But, I think the linked ups-future version already contains
that JIRA.

> <https://gist.github.com/matzew/35c3e3b12f78d2ed55f5#ups-200-march-2016>UPS
>> 2.0.0 (March-2016)
>>
>> In October (2015) the WildFly 10
>> <http://lists.jboss.org/pipermail/wildfly-dev/2015-June/004129.html> should
>> be released and I'd like to see us adapting this for the 2.0.0 series! Also
>> for a possible release of our 2.0.0 in March 2016, I’d like to stop the 1.x
>> series!
>>
>> *Note:* We don't have a release version for JIRA here, but heck! this
>> mail is asking for feedback ;-)
>>
>> *Key features / Core changes*
>>
>>    - UPS based on (public) APIs that are available in WildFly-10
>>       - looking at using WF feature packs
>>       <https://developer.jboss.org/wiki/WildflyProvisioning> (similar to
>>       what Keycloak did, e.g. for layered "product"
>>       - looking at getting an UPS sub-system
>>    - Java8 only (as well as making sure works w/ Java9)
>>    - internal communication fully based on messaging (A-MQ / HornetQ)
>>    - WildFly-Swarm launcher (aka fat JARs)
>>       - helps with a more modular system:
>>    - Modular system (e.g. different “webapps”, like "sender.war",
>>    "registration.war", "UI WAR" etc)
>>       - allows us to play with different platforms for the different
>>       “web apps”
>>       - e.g. for a 2.x.y we could see/experiment how a vertx
>>       microservice (e.g. for the device registration) will behave in the larger
>>       system
>>
>> I like that :)
>
>> Other new features, e.g. based on needs and/or requests could be weaved
>> into 2.0.0 or 2.0.x, based on timing.
>>
> I think we should consider some security features like certificates for
> registration etc ... But we can maybe discuss that in a different thread.
>

ah, right - good point, or at least getting rid of HTTP_BASIC and using the
KC bearer tokens for the sender and device APIs.

> Please review this initial draft of a roadmap - once we are all in
>> agreement, it's time to hammer the roadmap into stone, uhm... JIRA :-)
>>
>> Greetings,
>> Matthias
>>
>> --
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150709/c82d7c1a/attachment.html 