Fwd: [liveoak] Unable to use with iOS push notifications (#270)
by Matthias Wessendorf
I have seen that too, that some services allow no passphrase set. Some even
require no passphrase. (i think it was FB/Parse and/or Push.io)
If we make passphrase optional, we could help their users tool. At the end,
it's users choice to do so, or not.
Will create a JIRA for 1.0.0.Final to cover this...
-Matthias
---------- Forwarded message ----------
From: *Pauli Jokela* <notifications(a)github.com>
Date: Saturday, August 9, 2014
Subject: [liveoak] Unable to use with iOS push notifications (#270)
To: liveoak-io/liveoak <liveoak(a)noreply.github.com>
As the current AeroGear implementation does not allow for empty passphrases
when adding a push certificate, I'm unable to use the push notification
feature at all.
A lot of services out there require that a push certificate does NOT have a
passphrase set, so it's not an uncommon request.
—
Reply to this email directly or view it on GitHub
<https://github.com/liveoak-io/liveoak/issues/270>.
--
Sent from Gmail Mobile
11 years, 12 months
Preparation: UnifiedPush Server 1.0.0.Beta2 (was: Re: [UnifiedPush Server] release timelines)
by Matthias Wessendorf
Hi team,
now that keycloak-beta4 was released, we have an updated PR from abstractj
to use that version ([1]), combined w/ an upcoming release of our parent
(to leverage the kc-beta4 JARs), see [2].
At the moment we have a few open PRs:
https://github.com/aerogear/aerogear-unifiedpush-server/pulls
Please review, but DO NOT merge them! Why? The KC PR goes in first,
afterwards I will merge the other items, based on review feedback.
By tomorrow that all should be done (read: merged) and there will be a
staged repo for tests (and openshift updates), watch out for the email!
As mentioned on IRC, the nominees for the testing, are:
* sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj
Besides testing the UPS staging repo, please test our quickstarts
(including their client SDKs) as well:
* https://github.com/aerogear/aerogear-push-helloworld
* https://github.com/aerogear/aerogear-push-quickstarts
(use the master branch - there will be a .Beta2 TAG, if all goes well there)
Last but not least, please 'test' the documentation as well. For instance
the new UPS guide:
http://staging.aerogear.org/docs/unifiedpush/ups_userguide/
or other items of the new 'UPS doc center' :-)
http://staging.aerogear.org/docs/unifiedpush
Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after
that we can go to CODE_FREEZE for the 1.0.0.Final
Any thoughts ?
-Matthias
PS: others, besides the nominated folks, are welcome to test the things as
well :)
-Matthias
[1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008658.html
[2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008672.html
On Fri, Aug 1, 2014 at 6:35 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> Hi team,
>
> based on [1] I thought about our release timelines until 1.0.0.Final, and
> shortly after.
>
> -
>
> 1.0.0.Beta2
> <https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092/?selectedTa...>:
> 07/Aug/14
>
> This needs to include Keycloak-beta4, and might slip by one day, but not
> much more of a delay.
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years
AeroGear UnifiedPush server build feedback
by Bruno Oliveira
Good morning peeps,
I would like to open this thread to discuss some ideas about how to
improve the current build on Push server. Lukas have been doing a
stellar job improving it and I think we can help.
Yesterday I spent some time trying to build a developer environment for
UPS — was a good exercise to realize how people feel trying to contribute.
The goal was to build the environment from scratch.
Here comes some feedback (keep in mind that I'm not that good on Node.js)
- Build our dependencies takes a considerable time. For fair
reasons, we are running mvn install, npm install and bower install
for the first time. Maybe we can reduce one step?
- Java developers don't have their environment ready for Node — it can
be a blocker. For example, was necessary to install gcc, libpng and
libpng-devel. I already saw team members struggling with it, like me.
- Maybe we should run -Pdev by default and run the complete build only
for CI.
- Maybe we can minify some JS dependencies and don't build
everything altogether?
I built an image[1][2], because developers willing to just use UPS with the
latest bits might struggle to configure their environment and maybe it
can be helpful.
The image is not perfect and soon will be moved to jboss/dockerfiles.
Thoughts?
[1] - https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev
[2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/
--
abstractj
PGP: 0x84DC9914
12 years
[UnifiedPush Server] release timelines
by Matthias Wessendorf
Hi team,
based on [1] I thought about our release timelines until 1.0.0.Final, and
shortly after.
-
1.0.0.Beta2
<https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092/?selectedTa...>:
07/Aug/14
This needs to include Keycloak-beta4, and might slip by one day, but not
much more of a delay.
*Please note:* There is already works going on to have our parent and UPS
working w/ beta4 - it’s just a matter of merging the branch, once the
release is out.
Number of open JIRAs for this release is looking good!
-
1.0.0
<https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTa...>:
18/Aug/14
*Keycloak:* This will use keycloak’s beta4 as well, unless we find BLOCKERS
in their beta4... (As said before KC is mostly hidden inside the server,
and we can not wait for their 1.0.0.Final in September)
This release will be mostly around docs and perhaps some more UX review of
the quickstart demos. It is possible that the UX review does not happen.
*CODE FREEZE:* I’d suggest we do a *code freeze* for the UnifiedPush Server
on 11/Aug/14. This is pretty much shortly after the beta2 and gives us one
week of deep testing (of server, docs, demos) before the final release.
Next: *celebrate*!!!!!!!! [image: :tada:]
After the 1.0.0.Final of UPS, I’d suggest a two week-based release series
of small fixes and improvements, as well as taking up new Keycloak releases
-
1.0.1
<https://issues.jboss.org/browse/AGPUSH/fixforversion/12325080/?selectedTa...>:
01/Sep/14
*Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few items
from the JIRA.
-
1.0.2
<https://issues.jboss.org/browse/AGPUSH/fixforversion/12325081/?selectedTa...>:
15/Sep/14
*Keycloak:* main reason is pick-up of their 1.0.0.Final
-
1.0.3
<https://issues.jboss.org/browse/AGPUSH/fixforversion/12325082/?selectedTa...>
:29/Sep/14
Might not be needed - but added it to JIRA, just in case…
Let me know your thoughts and I will update the roadmap!
-Matthias
[1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years
Use of Differential Synchronization for data sync
by Randall Hauch
I’ve really enjoyed learning about what AeroGear has been doing with data sync. This is a tough problem, but finding a solution is really important. Both data sync POCs appear to use Differential Synchronization, or DS [1]. I was not familiar with the paper until today, but after reading it I do have a few questions/comments. Bear with me; this is a long post.
DS is clearly targeted for use within a collaborative document editor, where there are multiple clients concurrently editing the same document, and at any one time there are a relatively small number of documents being edited; you can get a feel for this by looking at figures 5 and 7 in the paper [1] — look at the amount of server memory and CPU required to perform DS on just one document being edited by a half-dozen clients. Also, in a collaborative document editor, clients are often continually making changes even as they attempt to synchronize with the server.
(It’s interesting that Google Docs, and Google Wave before it, appear to use Operational Transformation [2] rather than DS. OT might also make it easier to implement undo/redo, which works really well in Google Docs.)
An MBaaS or any other database-like service is very different. It has to host multiple applications (i.e., databases), each with multiple collections containing potentially millions of entities (e.g., JSON documents). The entities themselves are more fine-grained and smaller than collaborative documents (though probably a bit coarser-grained and larger than a single record in a RDBMS). Many clients might be reading and updating lots of documents at once, and the data service has to coordinate those changes. A single batch update from one client might request changes to dozens of entities. And the clients can/will always wait for confirmation that the server made the requested changes before continuing (unless the client is offline); or at a minimum can enqueue the requested changes.
Given these characteristics, using DS within the data service might be extremely expensive in terms of CPU and memory, and difficult for a DS-based service to implement all of the features necessary. First, the data service doesn’t really know which entities are being“edited”; instead, connected clients read entities, make changes locally, then request the service make those changes. Secondly, every time a change comes in, to compute the diff the service would have to read the persisted entity; this not only is inefficient, but this also makes it more difficult to scale and handle the concurrency, consistency, atomicity, and serializability guarantees. Thirdly, what would the data service need to do when a client connects and asks for the changes since it was last connected? The data service might be able to quickly find out which entities were modified since then, but computing the diffs (relative to the time the client last connected) for all of those changed entities would be very complicated. It may be easier and better for the data service to record the individual changes (edits) made by each transaction, and then to use that information to compute the effective diffs from some period of time. In fact, these recorded edits might also be useful to implement other features within the data service; see CQRS [3] and [4].
What is really required by the client when trying to synchronize its data after being disconnected? Assuming the client can say which subset of entities it’s interested in when it reconnects (via some criteria in a subscription), does the client want:
the new versions of those entities that changed;
the deltas in the entities; and/or
all of the events describing the individual changes made to all of those entities?
It may not matter for clients that don’t allow local offline changes, but what might the preferred approach be for clients that do allow offline changes? Option 1 is clearly the easiest from the perspective of the data service, but options #2 and #3 can certainly be handled. With option #1, can the client do something like DS and maintain copies of each original (unmodified) entity so that it can compute the differences? Does this (perhaps with a journal of edits made while offline) provide enough info for the client to properly merge the local changes, or does the client really need the individual events in #3 so that it can, for example, know that some local changes were made to now-out-date data?
Will the same option work for online notifications? After all, it’d be great if the same mechanism was used for data-sync, offline (push) notifications, and online notifications (events).
Finally, the data sync APIs of the data service should support the use of local client storage, but it should not require it.
Best regards,
Randall
[1] http://research.google.com/pubs/pub35605.html
[2] http://en.wikipedia.org/wiki/Operational_transformation
[3] http://www.infoq.com/presentations/Events-Are-Not-Just-for-Notifications
[4] http://martinfowler.com/bliki/CQRS.html
12 years