wording change
by Andres Galante
I've shared the new website at the UX team meeting today.
They think think that we should change the word "features" to "solutions" or "components".
It seems that it is hard to understand that aerogear is actually 4 different products and the word "features" doesn't reflect that.
What do you think?
9 years, 4 months
SITE: API Documentation and Specifications
by Matthias Wessendorf
Hi,
looking at andresgalante's long and scary list (
https://github.com/andresgalante/aerogearwebsite/blob/master/docs_structu...
)
I think for the "API Documentation and Specifications", we could perhaps
break that down into two differrent things:
#API Documentations
##Mobile SDK API Documentation (not sure about the name)
* AeroGear JS 2.0.0
* AeroGear iOS Http v0.1
* AeroGear iOS Oauth2 v0.1
* AeroGear-Push iOS 1.0.0
* AeroGear-OTP iOS 1.0.0
* AeroGear-Crypto iOS 0.2.3
* AeroGear Android 1.4.0
* AeroGear Android Auth 2.0.0-alpha.1
* AeroGear Android Authz 2.0.0-alpha.1
* AeroGear Android Pipe 2.0.0-alpha.1
* AeroGear Android Push 2.0.0-alpha.1
* AeroGear Android Security 2.0.0-alpha.1
* AeroGear Android Store 2.0.0-alpha.1
* AeroGear Cordova (lacks version?)
##Push API Docs
* AeroGear UnifiedPush RESTful APIs - stable
* AeroGear UnifiedPush RESTful APIs - development
* AeroGear UnifiedPush Java Client - Version 1.0.0
* AeroGear UnifiedPush Node.js Client (lacks version?)
* AeroGear SimplePush Java Client (lacks version?)
(yes, I removed some of the items, as I think they are not relevant in here
(see earlier email))
#Specifications
##Sync Specifications
* Client API Proposals
* Server API Proposals
These will be hopefully soon be gone and we have, similar to 'push'
specific API Docs for Sync (client/server)
Any thoughts ?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9 years, 4 months
User guide?
by Bruno Oliveira
Good morning, while reviewing some docs I started to consider to build
an AeroGear security user guide. At the same time I was wondering if
instead worth to build an AeroGear user guide with security being one of
the chapters.
The goal is to centralize que information in a single document. Into
this way people can read about it in ebook format or not.
Does it worth the effort?
--
abstractj
PGP: 0x84DC9914
9 years, 4 months
Concerns on JS Conflict Resolution lib
by Lucas Holmquist
So i have some concerns on the Current state of the conflit resolution POC that i created.
in it's current state, i had 3 methods in the api
* Read - just a GET
* Save - PUT/POST with an added "conflict" callback to handle the conflict resolution
* Remove - just a DELETE
This was all done before we wrote this spec
https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/
but even then, from the JS client perspective, it felt a lot like a pipe. In jQuery.ajax, you can actually listen for a "409".
The other thing that concerns me is that on the client side, people are using frameworks such as Ember, Angular, Backbone,etc... that have there own ways of doing server requests so i would hate to start re-inveting the wheel again.
while the read/remove don't really do anything different(they are just GET/DELETE's), the save method(PUT/POST) does. This is were all the "conflict resolution happens”. (what type on resolution algorithm, auto-merge, etc...)
I think it would be interesting to try to integrate this part into existing frameworks, rather than trying to create Pipeline again.
i think for node.js this might be interesting too, since we could create a piece of middleware that hooks into an express/connect request
Again, this might only be a concern on the JS client side, not sure what the other platforms are like in this regard
9 years, 4 months
Website structural changes and implementation
by Andres Galante
Hi!
Since the main discussion on the website now is weather what color to use I think we can move to implementation. Styling and color changes are not a blocker.
But before that, I want to make sure we have a solid structure. These are three concerns I've heard that we can discuss:
- Roadmaps should be feature specific instead of platform specific
http://andresgalante.com/aerogearwebsite/roadmap.html
- We should move Demos and Guides under "Get Started"
- I've changed main title to make sure the right audience (enterprise mobile developers) know this is a place for them.
Now it reads: "Bringing mobile and enterprise together." is it ok?
What do you think?
9 years, 4 months
