AeroGear Crypto Java 0.1.2 released
by Bruno Oliveira
Good morning, just to let you know we released today the bits for digital signatures and some bug fixes.
Have a happy new year sweet hearts.
--
abstractj
2 years
AeroGear WebPush Java Client
by Idel Pivnitskiy
Hi all!
I've just implemented a lightweight java client for receiving push messages
from AeroGear WebPush Server [1]. It is easy to use and fully async!
A few words about decision to use Jetty as a HTTP/2 client:
Currently there are only 3 Java libraries, which implement client side of
HTTP/2 protocol [2]: Netty, Jetty and OkHttp. I tried all of them:
- First of all I tried to use OkHttp. This is a lightweight http client
for Android and other Java apps. But currently this library supports HTTP/2
protocol only via old HTTP/1.1 API. It works well for simple
request-response, but its client API does not allow to use HTTP/2 features,
like Server Push Frames. I looked at GRPC [3], because Googlers use OkHttp
for HTTP/2 transport. But they don't use public API, they use only inner
classes to handle frames and built their own logic atop this classes. It
would be too complicated for our purposes.
- Secondary, I tried to refactor our WebPush console to a client
library. But this way is complicated too. netty-codec-http2 does not
provide a client API, it is only codec, low level protocol implementation.
- Now I use jetty-http2-client. It is easy to configure and use, fast
and async. Jetty provides a user friendly API to handle HTTP/2 streams and
get PUSH_PROMISE frames.
For more information, look at my commit history.
In the future, if there will be more lightweight alternatives than Jetty
(for example, new version of OkHttp or Java 9 API), I will rewrite the
transport layer of my library.
Here is an example, how to use my library [4].
[1] https://github.com/idelpivnitskiy/aerogear-webpush-java-client
[2] https://github.com/http2/http2-spec/wiki/Implementations
[3] https://github.com/grpc/grpc-java/tree/master/okhttp
[4]
https://github.com/idelpivnitskiy/aerogear-webpush-java-client/blob/maste...
Best regards,
Idel Pivnitskiy
--
E-mail: Idel.Pivnitskiy(a)gmail.com
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
8 years, 2 months
GCM Topics in UPS
by Summers Pittman
So I've got a few ideas for how to implement this, but I hope some people
more experienced with the platform can give some feedback before.
Quick Background:
In UPS right now we have a concept of categories. A single UPS message can
be broadcast to a bunch of devices which are subscribed to this category.
Google now supports this for GCM on Chrome, iOS, and Android so UPS can
send a single message to GCM and GCM will broadcast that to up to a million
devices.
End Quick Background
So first, how do we switch between sending a message to each device in a
category to sending a topic message to GCM?
In TokenLoader.java#L113 we are using the clientInstallationService to
build a string of deviceTokens based on the variant and message criteria.
Is there any reason we can't create a "topicToken" which will be recognized
later by GCMPushNotificationSender? Another benefit to making this change
here is that if we have over a million subscribers to the category we can
just default to the default messaging.
There is also an open issue of whether or not we will update the clients to
filter based on what category a message was sent to. To do this we will
have to include the category information in the message when we send it to
devices going forward. In GCM a topic message includes this information.
This means that if we have over a million subscriptions in the topic we
will need to fall back to using the category information anyway.
Continuing on from the thread of falling back, it is possible for a topic
message to fail to send because there are too many subscribers. How would
UPS handle regenerating the messages as deviceToken instead of topicToken
messages?
Of course if someone has a better idea than "topicTokens" I'm all ears.
8 years, 2 months
Adding ES6 to node sender
by Luke Holmquist
hello,
I just created a JIRA for the node ups sender,
https://issues.jboss.org/browse/AGJS-308, that tracks the addition of using
ES6(the next version of Javascript).
My thoughts were to use the new features where ever possible.
Since not every feature is available on all versions of node, we would use
Babel.js https://babeljs.io/ , to transpile that code back to ES5(the
version before es6 :)).
This transpilation would happen during an "npm publish" so users would
never really see a difference.
The cool thing about Babel is that we can specify which features we want
transpiled, so in the future this list of transpiled features would
hopefully get smaller and smaller.
The latest versions of node have a lot of new features in them, so it would
be nice to start coding that way. For instance, this plugin,
https://www.npmjs.com/package/babel-preset-node5 , is a preset for the
features that node 5 has.
wanted to get some thoughts on this.
-Luke
8 years, 3 months
UnifiedPush node sender
by Luke Holmquist
Currently the node sender for the UPS, is at 0.10.1,
https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/releases/t...
which works with the UPS version 1.1.x series.
Ive been thinking that perhaps we should update the node sender version to
be in lock-step with the version of the UPS it works with.
The only real problem with this is that the UPS 1.0.x uses the 0.7.x node
sender. but if we want to stay semver compliant, we can't really make a
1.0.x node sender series since it would "reverting" things in the 0.8+
versions.
I'm thinking that perhaps we just bump the node sender to 1.1.1? or
whatever the current release is of the UPS.
hopefully if we keep things like this, then it becomes less confusing for
users to know what version of the sender to use with which version of the
UPS
There is one issue i would like to get in though, before bumping the
version. https://issues.jboss.org/browse/AGJS-302 - this adds in using
the request library.
thoughts?
-Luke
8 years, 4 months
Heads up: WildFly 10 configuration incompatibilities
by Lukas Fryc
Hi guys,
in order to support WildFly 10+, that replaced HornetQ with ActiveMQ
Artemis,
we will have to change:
- WEB-INF/hornetq-jms.xml (primarily schema change, file rename would be
nice too, though it is not needed: *-jms.xml)
- jms-setup-wildfly.cli (again, subsystem addresses reflect
hornetq->activemq project rename, but stays compatible otherwise)
But that also means either:
- we will have to package WAR specific to WildFly 10+,
- or rather we should refrain from using *-jms.xml (bundled in WAR) and
use the pre-configured message queues instead (i.e. add bunch of
"jms-queue" add commands to jms-setup-wildfly.cli file)
- since we will make user to use that CLI batch file anyway (starting
with 1.2), I don't see a reason why not to include queues in CLI config
instead of WAR
WDYT?
Cheers!
~ Lukas
8 years, 4 months
