Non-Native Push Discussion
by Kris Borchers
Hey all,
So I wanted to start thinking about the spec and APIs that will be used for non-native push notifications. In order to do that, I first wanted to just throw my understanding of things and some very preliminary initial thoughts out there for discussion so we are all on the same page before any implementation begins. I have written those thoughts in this gist https://gist.github.com/kborchers/694f09159e85d861cf3b and have also pasted the contents of that gist below to provide easier inline comments and discussion.
Thanks!
#Non-Native Push (NNP)
The ability to "push" messages to a JavaScript client is an interesting yet complicated problem to solve. There are a number of factors to take into account. Below is a summary of some of those factors and thoughts on how to address them.
## NNP vs. Notifier
I first want to address the idea of NNP vs. Notifier as a whole. The way I see it, NNP is an adapter in the grand Notifier scheme. Notifier would be the umbrella object that would be a factory for generating notifier clients based on different adapters. There could be adapters for vert.x (thinking about renaming that adapter to SockJS since that's more what it is I believe), Atmosphere, or for purposes of this discussion, NNP.
## Server Side
On the server side, the NNP bits should be flexible. Since there is no defined method for sending a NNP message to a client like there is for native implementations like iOS and Android, the NNP parts should be flexible enough to work in tandom with those native bits. It should also be possible to send messages to only NNP clients, only native clients (both all native or by OS), all client types, or individual clients of a particular registered app. It would also be nice to be able to send NNP messages to individual devices which should be possible through either some sort of authentication system or via individual channels of currently connected clients. Another nice feature to have would be the ability to queue messages for NNP clients that are not currently connected. This would involve determining some method for message prioritization as well as expiration to avoid extremely long and/or oudated message queues. These messages could then be delivered when a particular client "phones home" either through the previously mentioned authentication method or channel subscription.
## Client Side
The client will also be very flexible in relationship to native push. Again, since there is no real standard for NNP, the client should be built to accept what ever unified payload is designed to work for the native push. That way this will again provide for seamless integration with the unified push.
The client will be built as an adapter of Notifier allowing an AeroGear user to manage all notification messaging (Push, Pub/Sub, etc) in one place. This means that the spec and APIs for Notifier need to be decided and documented before or at the same time as the NNP is being developed.
9 years, 11 months
Integrate custom route into "aerogear-android"
by tomlux
Hy,
I created a custom route (non CRUD) in my aerogear facade.
Using curl, I'm getting the expected results:
What is the easiest way to consume this route in "aerogear-android"?
As far as I understand, the pipe concept is just valid for the predefined
CRUD routes.
I also tried to solve my problem with "ReadFilter.setWhere", but I don't
know how I can/should configure this in the controller. The url was
correctly build, but the where condition wasn't repectet.
Thanks,
Tom
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Integrate-custom-route-into-aer...
Sent from the aerogear-dev mailing list archive at Nabble.com.
9 years, 11 months
Offline and Sync Brainstorm
by Summers Pittman
*
So for offline and sync for 2.0 I've been doing some thinking/research
and come up with some broad topics to discuss so we can start honing in
on what we want it to do/look like.
This isn't a spec, this isn't a proposal, this is just trying to narrow
down what we want at a high level so we can pick things to focus on.
1. Documents vs Transactions
There are two "big picture" methods of doing sync. One is a Document
sync (Think like a gallery with videos and pictures). Documents are
saved, the whole document is sent to the server, then the whole document
is pushed out to other clients who are syncing against the same source.
The other is a Transactional sync where many small atomic operations
are sent to the server. The best analog I have is Google
Drive/operation transforms.
Obviously the server side implementations of these are hilariously
divergent and I will leave the relative complexity of each as an
exercise for the list.
2. Background vs Foreground sync
Does the application have to be opened (foreground) for syncing to
happen? As far as I know, native Web requires this (barring extensions
to the browser, plugins etc). I think Cordova can in Android, but I
haven't researched it. iOS seems like a mixed bag, but generally you
can only sync if your application is in the foreground (but you can use
notifications and badges to communicate that there is a pending sync or
new data). I understand there is CoreData + iCloud that is supposed to
do something, but that seems like it is still foreground only. On
Android background sync is easy.
Is it OK to only have background syncing on some platforms but not others?
3. Push vs Poll?
Obviously pushing updates is better for devices and users, but polling
will let things work better for legacy services which may not have push
support or which may be difficult to integrate into AG-Controller.
Should we support both on the clients?
4. Multiple clients,multiple users, and conflicts
How do we want to support multiple users and multiple clients? How
should we try to do conflict resolution? What does authorization and
authentication look like here?
At a high level here are some options I have seen for conflict resolution:
A. Last in always wins. The server explicitly trusts things in the
order it gets and pushes that data out to users.
B. Clients are allowed one submit at a time and must wait for the
server to acknowledge the receipt. If there is a conflict the app can
either a) merge the data, b)reload the latest from the server and make
the user do his operation again, or c) create a new document and inform
the user.
C. Operation Transforms. This was meant to solve the conflict and
sync problem. However it is a LOT of work
5. Offline Support
Really this is more what do we want to do for coming from an "offline"
mode to an "online" mode? Abstractly, operations which happen offline
are the same as operations which happen online just with a REALLY REALLY
laggy connection. :) We could just only viewing data when offline and
requiring a connection for editing, queueing an upload, etc.
6. How much of this is the responsibility of AG-controller vs
underlying services?
How should the controller expose resources to clients, how should the
controller send data to its underlying services, how much data should
the controller be responsible itself for?
Should it be easy for an Operation Transform system to integrate with
AeroGear-controller?
Should it be easy to write a Controller based project which polls a
third party source?
How would the server handle passing credentials to the third party source?
Appendix Use Cases:
Here are a few contrived use cases that we may want to keep in mind.
1. Legacy Bug Trackers From Hell
a. It is a webapp written in COBOL, no one will ever EVER update or
change the code
b. It has TONS of legacy but important data
c. It has TONS of users
d. It only has a few transactions per day, all creating and updating
bug reports
e. Multiple users can edit the same report
2. Slacker Gallery
a. Each User has a multiple galleries, each gallery has multiple photos
b. A Gallery has only one user, but the user may be on multiple devices
c. Galleries may be renamed, created, and deleted
d. Photos may only be created or deleted. Photos also have meta data
which may be updated, but its creation and deletion is tied to the Photo
object.
3. Dropbox clone
a. A folder of files may be shared among users
b. There is a size limit to files and how much storage may be used
per folder
c. Files are not updated. If there is a new file, there is an atomic
delete and create operation
4. Email client
a. This is an AG-controller which accesses a mail account.
b. There are mobile offline and sync enabled clients which connect
to this controller.
5. Google Docs clone
a. Operational Transform out the wazzoo
b. What would the server need?
c. What would the client need?
Appendix Reference (Open Source) Products:
Wave-in-a-box
CouchDB
Google Drive RealtimeAPI
Can you guys think of more projects/examples to look at for inspiration?
*
9 years, 11 months
Push: Security / role model
by Matthias Wessendorf
Hi,
as you know the unified push server has a 'registration' component
(see here<https://gist.github.com/matzew/69d33a18d4fac9fdedd4> for
details; see here <https://gist.github.com/matzew/2da6fc349a4aaf629bce> for
REST APIs) which does the following:
- app registration and adding multiple variations
- registration of an installation, submitted from the device
There are different roles (as also discussed in the above links).... The
"app registration" functionality can be only achieved by something *like* an
"admin";
The admin can create a logical app construct on the server ( *Sport News
mobile* ), which has different variations:
- free for iOS/Android (no user required, everybody can install the app)
- paid (same, for both: iOS/Android): User is required, since they pay
for extra, exclusive content
Now.... the "logical" app construct on the server get's some ID, when the
app has been registered... (similar for each of the variants: iOS/iOS-paid
etc...)
This part of the registration needs to be protected, very well (e.g.
OAuth); just thinking out loud.... But yeah... only users, with the proper
rights should be able to register (update/delete) apps here!!!
<https://gist.github.com/matzew/e335881b3f95b1448774#deviceinstallation-re...>Device/Installation
registration
However, the other part of the registration (when an installation, from a
device, tries to register itself for wanting to receive messages), may be a
little more "weak"...
Scenario:
- Someone downloads the free iOS app:
- once he launches the app and he agrees on receiving push messages
- Now... the app should send the generated token (generated by the
actual Push Network), to the registration server... (otherwise it can't
receive push messages :-) ).
So...... the following information needs to be available.... so that the
mobile dev. for the free iOS app can register the token with the server:
- APP ID (+ mobile-variant ID)
Yes, the IDs are needed.... in order to tell the "registration server": *Hey,
this installation for XYZ wants to receive messages.....*
So, the iOS (client SDK) code could look like:
- (void)application:(UIApplication
*)applicationdidRegisterForRemoteNotificationsWithDeviceToken:(NSData
*)deviceToken{
NSURL *serverURL = [NSURL
URLWithString:@"http://pusher.server.com/registry/device/"];
PushClient *pclient = [PushClient appID:@"1234" mobileID:@"456454"];
[pclient registerDeviceToken:deviceToken withServer:serverURL
success:^(id responseObject) {
NSLog(@"Registration Success: %@", responseObject);
} failure:^(NSError *error) {
NSLog(@"Registration Error: %@", error);
}];}
The code above would be used by some customer/user, when they register
their app with their running version, of our Unified Push server..... Not
sure.... are we concerned about the keys are compiled into the actual app,
that everybody could download from the app store ?
We really can't issue a login in the above case, since there may be no
user..... and even if the paid app, requires a user..... someone can still
first buy the app, and after installation decide to register a new user,
from the app...... so the above code is still executed BEFORE the user
decides to active/register his account...
Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9 years, 11 months
Basic/Digest APIs on the client side, doable?
by Bruno Oliveira
Hi peeps, I was chatting with Kris and Matthias about how interesting would be the addition of Basic/Digest authentication for Android, iOS and JS.
The initial feeling is basic -> easy to add, digest -> tricky. Both methods are weak for security, but we still have developers dealing with the legacy and make their lives less painful would be nice.
Wdyt?
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
9 years, 11 months
integrate aerogear into existing jsf application
by tomlux
Hy,
I have a WEB-application based on JEE6 with CDI and JSF2 running on Jboss7.1
The security part is done be the "DATABASE" login module defined in
standalone.xml from JBoss.
The web application uses the security defined by "security-constraint"s in
the web.xml file.
Everything is working fine.
Now I want to start with aerogear, specially aerogear-android.
I have added the aerogear-controller with the picketlink authentication
successfully in my existing application.
My android-app can successfully login/logout and use the pipes to load the
data.
BUT, I have now *2 different authentication system*, the
DATABASE-login-module with the security-constraint-webxml and the
aerogear-picketlink.
Here the jboss config:
And the web.xml part:
How can I change to get the picketlink authentication working like the
DATABASE-login-module?
I want to handle the jsf-security part in the web.xml with
security-contraints, otherwise I should have to define a lot of "routes".
Thanks for any help/suggestions,
Tom
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/integrate-aerogear-into-existin...
Sent from the aerogear-dev mailing list archive at Nabble.com.
9 years, 11 months
AeroGear & Sinatra
by Bruno Oliveira
Morning slacker, yesterday I was doing some experiment using Sinatra with AeroGear. Here comes the final result: https://github.com/abstractj/todo-aerogear-sinatra
Disclaimer: Authentication was skipped and does exist a issue with refresh. Patches are more than welcome, brolyglots
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
9 years, 11 months
AEROGEAR-826 Android: timeout for pipe
by Summers Pittman
I've submitted 2 PRs. One is for the implementation and the other is for the integration tests.
Couple of quick things I want to bring up for comment:
1) I'm using controller-aerogear.rhcloud.com/aerogear-controller-demo as the base url for my tests and a timeout of 1ms. I doubt OpenShift will respond faster than that but it might be nice if we had a tarpit service where the http connection is made but no data is sent to make testing less reliant on swingy behavior. WDYT?
2) I'm defaulting the timeout to MAX_INT. HttpURLConnection (which does the heavy lifting) disables timeouts if a value of 0 is passed. Should timeout be defaulted to 0 instead? On the one hand I like having timeouts disabled by default, but on the other hand I feel like 0 is a very ambiguous value. MAX_INT very clearly means "don't time out for a very long time". WDYT?
Summers
9 years, 11 months
