AGJS Components
by Kris Borchers
I would like to start creating components for the AGJS project in JIRA. Here is the list I have come up with. Please comment, agree, add, remove as you see fit.
auth
pipeline
datamanager
courier
showcase
examples
docs
grunt-build
builder-node
builder-UI
dist <= this is for our dist build/repo
CI
11 years, 2 months
Update JS Roadmap
by Kris Borchers
Hey everyone,
Luke, Sebastien and I had a sync up this morning and put together a new JS roadmap. I wanted to lay out our releases in terms of the proposed overall AeroGear release schedule and make some tweaks based on our discussions. Please take a look at our new roadmap and let us know if you have any questions or concerns.
Here is the gist https://gist.github.com/kborchers/ff2ade823d9eceb687d1 and the content is below for easier comments. We hope to get your feedback over the next couple of days and then finalize this roadmap and add to the site by the end of the week.
Thanks!
# AeroGear.js Roadmap
## 1.0.x Release(s)
* **Bug Fixes and Minor Feature Additions**
* **Dates**
* Released as needed
* If not critical, can be wrapped into a 1.x release
## 1.1.0 (Late June)
### New Features
* **OTP**
* Sync with Bruno's works and help where needed
* **Notifier**
* Used for background communication in applications
* Adapters
* SockJS or some other fallback strategy
* More? (STOMP and other protocols to "unify" APIs)
* Can be moved to future releases
### New Adapters
* **Pipeline**
* OData Adapter - [http://www.odata.org/](http://www.odata.org/)
* Investigate continued support / viability (Netflix dropping?)
## 1.2.0 (Late August)
### New Plugins
* **SimplePush**
* Base on Mozilla's SimplePush Protocol Specification
* WebSocket/SockJS via Notifier
### New Adapters
* **DataManager**
* IndexedDB/WebSQL Adapter
* Feature detection to determine which is available
* IE9 supports neither so need to also be able to fall back to localStorage but use same API
* Probably should investigate PouchDB's implementation
* **Auth**
* OTP
* Adapter or standalone
* OAuth2 Adapter
* Customizable Provider
## 1.3.0 (Late October)
### New Features
* **Pipeline**
* Multi-part Uploads
* **DataManager**
* Add encryption to sessionLocal adapter
* **Showcase App**
* Incrementally released over other 1.x releases
## 1.4.0 (Late January)
### New Features
* **Data Sync**
* Utility for keeping data in DataManager synchronized with a persistent server side store
* Possibly use Notifier for communication / data transfer
* **Offline**
* Support for using apps offline and detecting status
* Simplified App Cache API
* Scaffolding for proper App Cache setup
* Use DataSync when returning to online status
## 2.0.0 Release
* Tie up any loose ends
## 2.x Release(s)
* **Social**
* Auth
* Login via Facebook, G+, Twitter?
* AeroGear.Auth adapter or separate?
* Common API
* Posting, Profile Info, Friend List, etc.
11 years, 2 months
Notifier … What's in a name?
by Kris Borchers
Sorry, I have a thing for silly subject lines.
So as I am working on a SockJS adapter for Notifier, I have come to the realization that Notifier is not a good name. The part of AeroGear.js does more than notify but instead provides the ability to build adapters containing APIs for both a subscription or pub/sub style communication system (i.e. push notifications) as well as a more complex communication system using things like STOMP.
My first question is whether or not Notifier is trying to do to much and if so, should it broken into 2 pieces like Notifier and Messager/Messenger (or something named like that)? Or, should the whole thing remain as one and just be renamed.
Thoughts?
11 years, 2 months
Give them a good home
by Kris Borchers
In our team meeting today, I brought up the question of whether or not the JavaScript clients for both SimplePush and Unified Push should live in folders under AeroGear.js or in their own repos. I would like to open this up to suggestions from the team. Please vote below.
SimplePush
Currently, this lives under AeroGear.js at https://github.com/aerogear/aerogear-js/tree/Notifier/src/simple-push
IMO, this makes sense since it also has a hard dependency on Notifier which lives here https://github.com/aerogear/aerogear-js/tree/Notifier/src/notifier
I would vote this remain where it is. Please vote whether or not this should remain in the AeroGear.js repo.
Unified Push
Currently, this lives under AeroGear.js at https://github.com/aerogear/aerogear-js/tree/Notifier/src/unified-push
IMO, this is not necessary since it could be used independently from the rest of AeroGear. I would vote that this move to a separate repo. This would also mean that the client object's name would change since it is currently namespaced under AeroGear as AeroGear.UnifiedPushClient. I would suggest it be renamed to AGUnifiedPushClient and be added to a repo named aerogear/unified-push-js. Please vote for whether or not this should move and if it should, an object name and repo name.
Thanks!
11 years, 2 months
double trouble
by Erik Jan de Wit
Hi,
Just to summarise here is what we found out when trying to create an Errai client for the TODO demo:
https://github.com/aerogear/TODO/pull/29
We have our own implementation that serialises JSON from and to objects that is compliant with Jackson and that seems to 'conflict' with the server implementation, because that is receiving Longs as javascript numbers. A number in Javascript is a Double and if you execute the following javascript you'll see that this leads to strange rounding problems
var test = {"id":1,"name":"tag","tags":[10000000000000001]};
console.log(test.tags[0]);
The same exists in Java
https://gist.github.com/jfuerth/5372442
What I've added to the server side of the demo is the ability to receive the ids as Strings and then convert them on the server side where such a number limitation does not exists.
Cheers,
Erik Jan
11 years, 2 months
iOS 1.0.1
by Matthias Wessendorf
Hi,
here are the items, resolved for the 1.0.1 versio of our iOS component:
AEROGEAR-1228 update Xcode template guide and describe the authentication
portion in the generated code
AEROGEAR-1225 iOS: Xcode Template needs Login hook
AEROGEAR-1224 iOS: Getting Started with AeroGear and Xcode is broken
AEROGEAR-1211 iOS: TravisCI: Enable Service hook for GH project
AEROGEAR-1210 test_Delete* integration test fails for Projects/Tags/Tasks.
AEROGEAR-1209 Update aerogear-ios-integration tests to use the AGPageConfig
AEROGEAR-1178 Update API docs and examples with the use of AGPageConfig
AEROGEAR-1144 Extract paging parameters to a PageConfig object
AEROGEAR-1136 Remove 'Auth-token' from iOS library
AEROGEAR-1114 ios: integration test: remove TODODAUTH usage
AEROGEAR-1113 iOS: API Doc: Remove references of TODOAUTH server
AEROGEAR-1104 iOS TODO app: change URL
AEROGEAR-1051 iOS: Pagination: Test with Reddit API
Have fun!
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 2 months
Security for "Device Registration"
by Matthias Wessendorf
Hi,
once the app is installed on the phone (or launched in a browser),
we (as discussed in the spec/mailing list) need to upload the "device
token" (or channelID) from the actual device/channel to the Unified Push
Server.
My questions:
Is it safe, if every "Mobile Variant" has a Private/Public Key ???
The UP server keeps the private one.
Once we register a new mobile variant (e.g. HR for Android, HR for iPad, HR
for iPhone, ...) EACH variant has ONE Private/Public key
The Public Key of this combo would be "coded" into the actual mobiel
application...
On EVERY iOS app, it would use the PubKey from the iOS Variant, on EVERY
JS-app, it would use the PubKey from the SimplePush Variant, etc
So, that means EVERY installation (on the devices) would have that pbulci
key...
Would that be (extremely) odd, if "1 Mio Russian hacker" would have that
public key, used on the device, to perform some sort of "auth" (e.g. via
HTTP BASIC (just saying.....)) against the server, in order to upload the
"device token" ??
Note: This Private/Public key would/should be EXCLUSIVE for "device
registration". And really ONLY.. :-)
So that this "Private/Public key" pair can NOT be used (==invalid) for
sending messages to the installations, or creating the Push-Applications /
Mobile Variant Constructs.
Greetings,
Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11 years, 2 months
