[RFC] future Roadmap for Unified Push Server
by Matthias Wessendorf
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)
- 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-d...>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
<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
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.
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
10 years, 10 months
UPS Node Sender client categories issue?
by Fink, Miles
Hi,
I’m just starting out with UPS (which is awesome btw!) and the Node.js sender client. One thing I’ve noticed is that a message sent from the dashboard with a particular category is sent to only those installations that have that category listed. This works great and is expected. I’m glad there is a way to target specific notification channels, etc.
Sending a notification via the Node Sender client however appears to be sending to everyone’s installation regardless of the categories sent with the message. Here’s a pastie of what my node client call looks like: http://pastie.org/10282358
I’m using:
Unifiedpush Node Sender version 0.8.0-beta1
UPS is the setup via the openshift cartridge, from https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/opensh...
Any pointers would be greatly appreciated. Very well could be me doing it wrong… ;-)
Thanks,
Miles
10 years, 10 months
One JIRA instance to rule them all? (was Re: AG JS JIRA)
by Matthias Wessendorf
That brings me to something .... :-)
using this approach,e.g
* android-oauth-3.0.0
* swift-sender-1.0.0
* ios-swift-push 3.0.0
we could go back and just use one JIRA.
That's perhaps less confusion for our users :-)
They just enter bugs/issues and we are responsible for the actual 'triage'
(e.g. set correct components and versions)
:-)
On Thu, Jul 16, 2015 at 11:01 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> well... the use of components makes it easy - and for versions we could
> even do something like, for instance in AGJS
>
> node-1.2.0
> store-0.7.0
>
> etc
>
>
>
> On Thu, Jul 16, 2015 at 10:42 AM, Lukáš Fryč <lukas.fryc(a)gmail.com> wrote:
>
>> I know there already is strong agreement, but my $0.02:
>>
>> I'm not convinced about AGJS and connection with server-side libraries.
>>
>>
>> I feel like AGIOS, AGDROID, AGCORDOVA, AGJS are trackers for client-side
>> libs,
>>
>> AGPUSH, AGSYNC, are trackes for server-side technologies,
>>
>>
>> consider this use case: if we build eventually a new server-side Swift
>> node-sender library, we won't track it under AGIOS because Swift comes from
>> iOS land.
>>
>> On Thu, Jul 16, 2015 at 8:42 AM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>>> word up👍
>>>
>>>
>>> On Thursday, July 16, 2015, Daniel Bevenius <daniel.bevenius(a)gmail.com>
>>> wrote:
>>>
>>>> +1 Sounds good
>>>>
>>>> On 15 July 2015 at 22:52, Daniel Passos <dpassos(a)redhat.com> wrote:
>>>>
>>>>> +1
>>>>>
>>>>> On Wed, Jul 15, 2015 at 4:21 PM, Bruno Oliveira <bruno(a)abstractj.org>
>>>>> wrote:
>>>>>
>>>>>> +1 makes more sense
>>>>>>
>>>>>> On Wed, Jul 15, 2015 at 3:29 PM, Luke Holmquist <lholmqui(a)redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> we've decided that it would probably be a good idea to move JIRA's
>>>>>>> related to the node-sender to the AG-JS JIRA instead of having them on the
>>>>>>> AGUSH JIRA.
>>>>>>>
>>>>>>> i think this makes a bit more sense since this a javascript
>>>>>>> component.
>>>>>>>
>>>>>>> I've started to move open JIRA's over. i think i'll probably just
>>>>>>> leave the existing JIRA's where they are, unless someone feels strongly.
>>>>>>>
>>>>>>>
>>>>>>> I've also started to create some "component" versions similar to the
>>>>>>> other projects.
>>>>>>>
>>>>>>> the main JS lib will still be just numbers, like 2.3.0, and for the
>>>>>>> node-sender we will now have node-sender-0.8.0, for example
>>>>>>>
>>>>>>>
>>>>>>> -Luke
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> --
>>>>>> "The measure of a man is what he does with power" - Plato
>>>>>> -
>>>>>> @abstractj
>>>>>> -
>>>>>> Volenti Nihil Difficile
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -- Passos
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Sent from Gmail Mobile
>>>
>>> _______________________________________________
>>> 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
10 years, 10 months
AG JS JIRA
by Luke Holmquist
Hello all,
we've decided that it would probably be a good idea to move JIRA's related
to the node-sender to the AG-JS JIRA instead of having them on the AGUSH
JIRA.
i think this makes a bit more sense since this a javascript component.
I've started to move open JIRA's over. i think i'll probably just leave
the existing JIRA's where they are, unless someone feels strongly.
I've also started to create some "component" versions similar to the other
projects.
the main JS lib will still be just numbers, like 2.3.0, and for the
node-sender we will now have node-sender-0.8.0, for example
-Luke
10 years, 10 months
aerogear-ios-push Carthage support
by Robert Oschwald
is it planned to add Carthage support to the library?
We moved away from Cocoapods since a while and love Carthage for beeing non-intrusive.
Thanks,
Robert
10 years, 10 months
Help! (was: Re: Cordova Push - 1.0.3 release (was: Re: Push plugin for Cordova))
by Matthias Wessendorf
I need help :-)
a few 'problems'
* there is already a 1.0.3 TAG - but was not published (not a big deal - we
will just do 1.0.4 instead)
* I can not publish the 1.0.4 stuff - this is a real problem/blocker :-(
here is my
> plugman publish .
I am getting this error:
<error>
attempting to publish plugin to registry
npm ERR! publish Failed PUT response undefined
Error Code: undefined
login error
</error>
Unfortunately the current published 1.0.2 is broken and does not work...,
another pity is the 'old' registry (where our 1.0.x stuff is located) is
read-only by tomorrow:
http://cordova.apache.org/announcements/2015/04/21/plugins-release-and-mo...
So... we can only update it today :-)
If one of you, that did push some plugins in the past (Erik in on
vacation), could help out here and push the 1.0.4 TAG to the registry? It's
highly appreciated.
thanks,
Matthias
On Tue, Jul 14, 2015 at 2:30 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> Hi,
>
> now that we merged the PR from Martin, and the given fact that the old
> plugin registry is read-only, starting tomorrow, I'd like to push a release
> of the 1.0.3 version, using this branch:
>
> https://github.com/aerogear/aerogear-cordova-push/tree/1.0.x
>
> Any thoughts?
>
> On Tue, Jul 14, 2015 at 1:35 PM, Martin Murphy <mmurphy(a)redhat.com> wrote:
>
>>
>> On 14 Jul 2015, at 12:16, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>
>>
>>
>> On Tue, Jul 14, 2015 at 1:11 PM, Martin Murphy <mmurphy(a)redhat.com>
>> wrote:
>>
>>> Hi Matthias,
>>> That would do, however I was think more of this way:
>>>
>>> https://github.com/mmurphy/aerogear-cordova-push/commit/73198edf6364c93ca...
>>> to avoid the risk of pointing at a changing repo.
>>>
>>
>> sounds good!
>>
>>
>>>
>>> Can use the one you mentioned, or a combination of them?
>>>
>>> I can certainly do the PR.
>>>
>>
>> that would be awesome
>>
>>
>> Is this sufficient?
>> https://github.com/aerogear/aerogear-cordova-push/pull/74
>>
>>
>>
>>>
>>>
>>> Best Regards,
>>> Martin Murphy.
>>>
>>>
>>> On 14 Jul 2015, at 11:59, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>>
>>> Hi Martin,
>>>
>>> so - it's basically porting this commit over to the 1.0x branch:
>>>
>>> https://github.com/aerogear/aerogear-cordova-push/commit/ac1bcc624db98d5a...
>>>
>>> right ?
>>>
>>> Mind sending a PR ?
>>>
>>> On Mon, Jul 13, 2015 at 5:59 PM, Martin Murphy <mmurphy(a)redhat.com>
>>> wrote:
>>>
>>>> Hi folks,
>>>> we have a Cordova application that’s using Codrova 3.3.
>>>> The application uses org.jboss.aerogear.cordova.push 1.0.2
>>>>
>>>> When preparing for an android build, there seems to be an problem
>>>> installing one of the dependencies of the aurora plugin
>>>> An id has been updated: com.vladstirbu.cordova.promise, now has a
>>>> different id: es6-promise-plugin.
>>>>
>>>> The newer plugin 2.0.2 is in the npm registry.
>>>>
>>>> Is it possible to add a fix and deploy to the old cordova registry so
>>>> that it’s usable in 3.x
>>>> Is the newer plugin 2.0.2 backward compatible with 1.0.2
>>>>
>>>> I understand that the ideal approach would be to use a more up-to-date
>>>> version of Cordova, and use the latest aurora plugin, however it will take
>>>> some time before I will be able to do that.
>>>> I’m open to other suggestions also.
>>>>
>>>> Best Regards,
>>>> Martin Murphy.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>> _______________________________________________
>> 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
10 years, 10 months
AeroGear Android 3.0 - Roadmap
by Daniel Passos
Hey Guys,
As you know Summers and I started work on AGDroid 3.0. Today we revisited
what we want to this release. I hope you enjoy it
GOALS
- Remove Java 6 support
- Move to $LATEST android-maven-plugin
- GCM 3.0 + Push Tasks
- Extra convenience tooling
- Memeolist demo app
- Update docs
- oAuth2 improvements
- Experimental Offline Module
- Experimental Yubikey Neo support
Aerogear Android Push
- GCM 3.0
- Instance ID
- This is a new lifecycle for keeping the registration ID in sync
- Using new services and broadcast receivers or providing
equavalent support
- XMPP
- Using XMPP messaging for receiving messages and sending analytics
updates
- May be basis for more robust client side diagnostics and/or
eventual messaging APIs
AeroGear Android plugin (new)
- Previously we shot this idea down because it adds work on developer
which isn’t standard
- Google is moving to including more plugins in Gradle so that isn’t a
concern
- Goals
- Linting push and authz
- Confirm services in manifest
- Confirm appropriate licecycle on Message Listeners
- Annotation Processing
- Automate boring lifecycle tasks around Push (attaching/detaching
listeners from activity)
- Manifest processing
- Inject Required services for push and authz if libraries are
present
- Automatically configure these services with values from
keycloak.json and push-service.json
AeroGear Android Cookbook
- Memeolist Demo App
- Show off Material design skills
- Show off integration with other Red Hat/JBoss technologies
- Increase profile of AeroGear inside of Red Hat
- Dogfooding
AeroGear Android Pipe
- Logging support
- Easier injection of HTTPProviders
- Document adding custom headers under pipe
AeroGear Android Store
- Decide between
- Async operation
- Content Provider
- With the plugin we could also engage in automatic contract
object generation
- For an example of what I am thinking see Contracts
<https://github.com/secondsun/devnexus-android-2015/tree/master/devnexuscl...>
and ContentProvider
<https://github.com/secondsun/devnexus-android-2015/blob/master/devnexuscl...>
AeroGear Android Offline
- Cache : Configurable storage mechanism
- Location : Where the CaceItem will be stored
- Memory : in Memory store.
- OnDevice : the internal permanent storage of the device
- Media : removable media based storage. SD Cards, USB Sticks, etc
- Eviction Policy : How long CacheItems can stay around
- Permanent : Cache items must be removed manually
- LRU : When the cache is full the least recently accessed will be
removed
- Fifo : The oldest object in the cache will be removed.
- Size : The max number of items a cache may hold.
- Age : The max age of any item
AeroGear Android Authz
- Revisit oAuth2 opened jiras
AeroGear Android Security
- Experimental Yubikey Neo
<https://www.yubico.com/products/yubikey-hardware/yubikey-neo/> support
PS: Jiras are comming soon
--
-- Passos
10 years, 10 months
