I'm going to create a few JIRA issues for AeroGear WebPush Server and Java
Client. So, I think that it would be reasonable to create a separate JIRA
project for all issues for WebPush.
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
I'm really unhappy with number of breaking changes that has appeared in the
latest staged 1.1.0.Final - mostly these changes were related to massive DB
schema updates. I'd expect such changes to happen in Alpha phase and not in
between Beta3 and Final.
I understand that a lot of these changes have been driven by late inclusion
of migrator to 1.1 branch. That said, what is the plan with 1.1.0.Final?
Are you guys going to remove the changes or at least make sure they do not
impact users running Beta3? I've seen it has been de-staged and there have
been a few commits reverting DB changes back. Is there any estimate when
1.1.0.Final will be restaged?
QE plan is to make sure that migration from 1.0.3 is smooth, however we
also want migration from Beta3 to be smooth.
You might remember that we wanted to add the aerogear push plugin to the
ng-cordova project. So we create the PR, half a year ago and now 3 PR's 
later we have been added! Now getting started with cordova, angular and
push is super easy. Keep an eye out for the next release.
/wrt the GCM Topics support PR
me and summersp have discussed how JMS should be used to route messages.
Current implementation loads tokens and conditionally sends either message
with registration IDs or topics.
There are two things yet to be solved:
- topics can be used up to 1 million registrations, otherwise you have
to fall back to enumerating registration IDs
- implementation with one sender (GCMPushNotificationSender) is
- the utilization of the topics can be increased by prioritizing
topic message sending first (covering multiple, potentially thousands
- followed by sending registration IDs out
That's why I suggested to split implementation to two JMS queues talking to
two sender impls (e.g. GCMTopicSender and GCMRegistrationIdsSender).
- first we send out topic based messages (for efficiency)
- we collect those topics that fail and resend them for processing as
registration IDs (fail over)
- registration ids sending can start in parallel, but it can't end
until we sent out all topics
Additionally we get an ability to configure these two message routes
individually on the JMS level (better utilization, transact-ability, fail
What do you think?
can somebody who worked on UPS migrator recently, check if it deals with
recent database changes (e.g.
I have run into error when running integration test with migrator run
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Key column
'variantInformations_id' doesn't exist in table).
Thanks for any help.
Mobile QE Intern
So it looks like the work for properly supporting topics is going to grow.
So far we have identified two areas for improvement already :
* lfryc and I met this afternoon and discussed how to handle topic
failures where calling back to registrationIds is appropriate. He has some
refactors he wants to make.
* Last night on the -users list a community member brought up some use
case we have to consider as well. Specifically around how `alias` and
`deviceType` interact with topics.
In the spirit of keeping the PRs manageable, I propose we create a feature
branches for topics in aerogear/aerogear-unifiedpush-server and
Barring strong opinions against this, I will create these branches and move
my PRs appropriately.
Guys and gals,
UPS is currently using a fork of Google's rest-client sample to communicate
with Google's servers (See the previous thread UPS and com.ganyo:gcm-server
for details**). This is an outdated fork from https://github.com/google/gcm.
It is in fact very outdated. The rest client code, Message and Builder
objects, Constant fields, and Sender code don't support all of the
fields/errors/etc needed for GCM topics messaging. Additionally it uses a
deprecated field in a few places. I've filed two* issues*** in the gcm
project to reach out and begin work with them to resolve this in a more
sane way. In the meanwhile we will probably have to patch and support our
own fork of the library.
Thoughts, comments, tomatoes?
PS, this will probably bump XMPP support from aerogear-android-push 3.0 and
UPS 1.2. Please let me know if it should and i will pull those from the
JIRA epics and we can reschedule them.