[SimplePush] Registration of "Mobile Variant instance" w/ Unified Push Server
by Matthias Wessendorf
Today, with SimplePush and the Unified Push, we treat every channel as a
"Mobile Variant Instance".
Does that really make sense?
* Imagine a web-app, that has subscribed to three channels:
- mail
- chat/IM
- HR-system
These are really three different applications (different buisness logics),
while a "Mobile Variant Instance" is representing one "installation" of the
APP (e.g. hr-iOS installation or hr-Android installation).
Something like:
- Mail
- chat/IM
- HR-System
would be three different PushApplications, in the Unified Push server. That
could have their own variants (e.g. Mail-iOS, Mail4Android,...)
I think, that it's currently wrong to register multiple channels for a
MobileVariant. Perhaps I am wrong, but why would the SimplePush variant of
a "Sports App" require more than one "sports" channel? If we would allow
multiple channels, I think, we are mixing concepts here.
I come to this, when thinking a bit more about the "unification" of the
Message Formats
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 10 months
Latest Android SDK breaks our maven builder.
by Summers Pittman
https://code.google.com/p/maven-android-plugin/issues/detail?id=377&sort=...
So right now if you have the latest SDK maven can't build the project.
Worse, the fixed version isn't in maven central yet.
I'm sure it will be fixed sooner rather than later (given how many
people must use it), and there is a workaround in the bug report.
Do we want to
1) Put the workaround in the project's README until it isn't necessary
2) Host a patched version of the plugin on jboss nexus and configure the
pom to run against it
3) Post instructions for how developers can patch/update their local
install of the plug-in
4) Wait patiently until the fix makes it into central
5) Something else I overlooked.
10 years, 10 months
AGSEC - Component planning
by Bruno Oliveira
Good morning all.
Today most of the tasks related with security on AeroGear
(https://issues.jboss.org/browse/AEROGEAR) were moved to
https://issues.jboss.org/browse/AGSEC.
How to properly file jiras?
Once security is a cross-cutting concern affecting most part of the
projects on AeroGear, people might get confused about how to file a JIRA
for security.
So here comes my recommendation:
- Issues related with specific projects like JS, Android and iOS should
be created into the respective jiras: AGJS, AGDROID and AGIOS. (is my
suggestion only)
- If the issue is something that abstractj|slacker should definitely
take a look or should work on it, please, create a link into AGSEC. For
example: https://issues.jboss.org/browse/AGSEC-28
Here is the list of planned components for the AGSEC project in JIRA:
- examples: demos, example of usage, snippets
- docs: documentation about how to make use of security libraries, blog
posts, updates on aerogear.org
- CI: updates on CI like new jobs to be created or improvements
- OTP: TOTP & HOTP components which affects the server, iOS, Android and JS
- crypto: implementations of cryptographic algorithms to support
server/client side
- security-*: aerogear-security, aerogear-security-picketlink and
aerogear-security-shiro.
- social: Twitter, Facebook, Google (any social networks to share your
password with friends)
- auth: authentication methods to be provided (Basic, Digest, LDAP,
OAuth2, Hawk, Mozilla Persona, Two-factor)
- authZ: authorization methods to be implemented or supported.
- storage: issues and features related with encrypted storage
- cache: issues and features related with encrypted cache
Please let me know wdyt. Once it will affect the whole project, feedback
is important.
10 years, 10 months
[SimplePush] Sockjs support
by Daniel Bevenius
Hi,
I've been working on adding support for Sockjs to the SimplePush server.
There is a project named socksj-netty [1] which is an external project
written for Netty 3.x.
We are using Netty 4 and there have been quite a few changes between these
two versions. I've spent some time already trying to upgrade to Netty 4 but
I have not been completely successful. Testing has been hard as there is
only an external test suite [2], so it's been a matter of getting the code
base to compile and trying to change as little as possible to work with
Netty 4.
Perhaps due to my lack of understanding the sockjs-protocol I've found this
to be somewhat of guess work. There are also parts of the sockjs-protocol
that I'm not sure are implemented, like heartbeats.
I'm now considering rewriting the sockjs-netty and use the "Netty 4 way".
This will take some time which was not planned for.
Another option that Matthias brought up was to instead use Vert.x. It was
discussed previously what we should base our implementation on and I got
the impression that we "should" stick with Netty. I've been very happy with
Netty and would like to continue with it, but this might be that I'm more
familiar with it compared to Vert.x.
So I'd like to hear what people think:
1. Implement Netty Sockjs
2. Switch to Vert.x instead
thanks,
/Dan
[1] https://github.com/cgbystrom/sockjs-netty
[2] https://github.com/sockjs/sockjs-protocol
10 years, 10 months
Simple Push Server Verticle
by Sebastien Blanc
Hi,
This weekend I've been playing with Dan's Simple Push Server implementation
( https://github.com/danbev/aerogear-simplepush-server/ ) and I started to
write a vert.x implementation of the server.
But ... why ?
* By nature, vert.x is meant for asynch applications and Simple Push was a
perfect fit.
* It can easily scale just by running more verticle instances (and soon
deployable on openshift)
* Showing how Dan's server can be used as "library", indeed the vert.x
implementation consist just in one script, a verticle, relying on the
protocol jar and the server impl jar.
* Removing boiler plate code, vert.x APIs wrap a lot of Netty's logic.
Basically, the script replace the Netty package of the server
implementation
https://github.com/danbev/aerogear-simplepush-server/tree/master/server/s...
* It's fun and written in Groovy (and because it's vertx, it would be easy
to port it to Java, JavaScript or Python, we are brolyglot ! )
So, it's really early/alpha work, a lot of stuff is missing right now but
if there is interest, we could add these (security, scheduled "cleaner"
verticle ...).
You can find it here
https://github.com/sebastienblanc/aerogear-simplepush-server/tree/verticl...
and
use the websocket demo page of Pushee, just as for the server version.
Instructions are included in the readme.
10 years, 10 months
Basic/Digest Auth and JS
by Kris Borchers
So, having seem the plans around Basic and Digest auth for Android and iOS, I am wondering if there is any need for that on JS. Typically that is handled by the browser and them the server maintains the session so I would lean toward not needing anything specific in JS for these types of auth. Input welcome.
Kris
10 years, 11 months
