Latest Updates to AeroGear.js
by Kris Borchers
I have made a number of changes to AeroGear.js since the 1.0.0.Alpha release. I would appreciate it if you would take a look and let me know what you think or send any feedback and questions you might have.
So me of the new things added are:
Separation of data handling from Pipeline into a new component called DataManager
Moved the filter method out of Pipeline into DataManager - Data can still be filtered in Pipeline on the server side but client side filtering will happen in DataManager
Added a baseURL parameter to Pipeline for easier config of endpoints
Upgraded QUnit and add QUnit Composite to be able to run all test suites from a single page
As a reminder, the repo is here https://github.com/aerogear/aerogear-js and a good way to see usage examples is to take a look at the unit tests here https://github.com/aerogear/aerogear-js/tree/master/tests/unit. Also, the docs are also available here http://aerogear.github.com/aerogear-js/
Thanks,
Kris
12 years, 4 months
Updated Android example
by Glen Daniels
Hey folks,
Based on some conversation in IRC yesterday, I updated my Android sketch
further. In addition to supporting creation and deletion of tasks on
the rhcloud server, there's now an abstraction called
AeroGearCollection, which works like this:
tasks = new AeroGearCollection("tasks", Task[].class);
tasks.add(new Task("Arrange rental car"));
AeroGearCollection associates a backend URL with a Java class for JSON
mapping and a set of operations.
Check it out at https://github.com/gdaniels/android-data.
A couple of points:
1) AeroGearCollection seems similar to, but perhaps not quite the same
as, the Pipe abstraction?
2) The AeroGear "libary" stuff (in the org.aerogear.android package)
does not itself deal with asynchrony/Intents/Services/etc, and that's
left to the application (org.aerogear.proto...). In the near future we
may want to provide these components so as to make the user-facing APIs
simpler to use.
Thoughts/questions/comments appreciated.
Thanks,
--Glen
12 years, 4 months
Proposed Organization for our Site
by Douglas Campos
Howdy again
I was thinking on how should we organize our site + generated docs. We've been talking on hosting api.aerogear.org, but Kris remembered me of how important is to have separated -dev and -stable docs.
So my first proposal for this org is:
aerogear.org for our production site - generated from our 'production' branch
staging.aerogear.org the same for 'staging' branch
api.aerogear.org/<subproject>/ for API docs? how should we differentiate from stable and dev? IMHO we need to have consistence across the projects, but at the same time I'm out of ideas apart from api.aerogear.org/aerogear-js/1.0.0.Alpha1/ (version component is the last, being 'current' or 'dev' the current versions)
thoughts?
-- qmx
12 years, 4 months
mass-unsubscribes
by Douglas Campos
Just to avoid confusion, I've unsubscribed everyone from the old list - you all should be set to use the new list <aerogear-dev(a)lists.jboss.org>
-- qmx
12 years, 4 months
Fwd: [Aerogear-dev] Survey of web apis for persistence and basic security
by Douglas Campos
Begin forwarded message:
> From: Marko Strukelj <mstrukel(a)redhat.com>
> Subject: Re: [Aerogear-dev] Survey of web apis for persistence and basic security
> Date: August 31, 2012 5:46:46 PM GMT-03:00
> To: Jay Balunas <jbalunas(a)redhat.com>
> Cc: aerogear-dev <aerogear-dev(a)redhat.com>
>
> This is great. More inline ...
>
> ----- Original Message -----
>>
>>
>> First, thanks for writing this up!! Its useful to see this all on one
>> place.
>>
>>
>> Data-binding to classes or generic property bags?
>>
>> * We want to take advantage of JavaEE, BV, etc... I think binding to
>> classes will be important for this.
>> * This does lead to portability concerns, because while Android is
>> Java, iOS and others are not
>> ** We'll need a metamodel for this, and should to things like OData
>> and others
>>
>
> I see this as purely client API concern. With either approach the data then has to be marshalled into some data exchange format for shipping to the server, and the opposite operation when received from the server. The most natural format for aerogear-client to REST is JSON I dare say.
>
>>
>> How to handle data relations?
>> * One of the best ways I've seen of handling this is to link to have
>> options for some depth to be included
>
> Yes, client could send a filter as part of fetch operation. Default could be everything. And then you could exclude.
> {exclude: "User.Address"}
>
>> * Any circular, or deep relationships should be a "link" object of
>> some sort that points to the resource if needed
>>
> I think for synchronization optimizations like this make sense. Not sure if it makes sense for simple fetch, where you already filter out data you don't want with exclusion filter. Having duplicates of full structure i.e.
>
> city: {name: "San Francisco", zip: "94103"}
>
> as opposed to reference
>
> city: {ref: {type: "City", id: "94103"}}
>
> Makes client side much simpler to process the data.
> When references are involved you have multiple ways of handling that. You can include one copy of the entity for each reference in the response so that you make sure the data is fresh. Or you may leave to the client to decide whether to use locally cached data (maybe good enough from client point of view) of whether to request the latest from the server, which is a really a sync operation to make sure you have fresh data on the client. But when you don't do this as part of a single request/response you can't have tx consistency for the data.
>
> Having references gives rise to many options and makes things quite more complex :)
>
>>
>> How to handle binary data?
>> * Blobs can be hashed, and sent as is, but would likely need a
>> header/mimetype
>>
>
> I imagine blobs are URL resources, so in JSON just include a URL to the blob.
>
>>
>> Explicit class schemas or schemaless
>> * I want to make sure we're talking about the same thing, can you
>> explain more?
>>
>
> You mean something like JSON Schema (analog to xsd in JSON world)? If you want automatic entity class generation for access to REST endpoint that has some data, then you need some schema which describes the data.
>
>>
>> How to best handle local caching + sync?
>> * This would be partially based on the client, but also on the
>> serverside.
>> * For our initial impl basic local caching is fine (or we leave it to
>> the end user for now)
>> * Sync, and more advanced offline syncing can wait for phase 2 imo
>>
> Yes, that's a big topic :)
>
>>
>> Provide atomic counters? (most of these libraries do)
>> * Yes, we'll likely need something like this.
>> * Matthias - do you have any previous experience with this
>> requirement?
>>
> You mean to use autoincrement counters for IDs? You can't generate those on the client so whenever you need to increment that's a serverside operation. And on the server that's a single node operation - you need a cloud-wide singleton that handles this for all clients... That's a big downside, as your app now has a scalability chokepoint. I think for IDs it's best to use GUIDs where you don't have some other semantic id. They are globally unique so you can generate them on the client (presuming they are correctly implemented, and that there's a good random generator used :).
>
>>
>> Manage clients with API keys?
>> * That is a common way to do this
>> * We should outline the different options
>>
> API keys are used to control public access to certain server endpoints and provide ability for QoS, right? An API key is tied not to a single user or a single client device but to client app. And requires quite an advanced infrastructure with management UIs ... and it's for consumers of the APIs to use, and for providers of APIs to have monitoring tools and administration tools. I think that's something way out into the future ... Or maybe you have something else in mind :)
>
>>
>> Other questions:
>>
>>
>> Model/entity based client storage, or database replication?
>>
> Another big one :)
>
>>
>> On Aug 31, 2012, at 2:41 PM, Jay Balunas wrote:
>>
>>
>>
>> Hi All,
>>
>>
>> I'm posting Glen's gist on his review of existing apis for BaaS
>> operations - https://gist.github.com/3495006
>>
>>
>> Any comments and feedback welcome!
>>
>>
>> -Jay
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)redhat.com
> https://www.redhat.com/mailman/listinfo/aerogear-dev
-- qmx
12 years, 4 months
Fwd: [Aerogear-dev] Survey of web apis for persistence and basic security
by Douglas Campos
Begin forwarded message:
> From: Jay Balunas <jbalunas(a)redhat.com>
> Subject: Re: [Aerogear-dev] Survey of web apis for persistence and basic security
> Date: August 31, 2012 4:12:41 PM GMT-03:00
> To: aerogear-dev <aerogear-dev(a)redhat.com>
>
> First, thanks for writing this up!! Its useful to see this all on one place.
>
> Data-binding to classes or generic property bags?
> * We want to take advantage of JavaEE, BV, etc... I think binding to classes will be important for this.
> * This does lead to portability concerns, because while Android is Java, iOS and others are not
> ** We'll need a metamodel for this, and should to things like OData and others
>
> How to handle data relations?
> * One of the best ways I've seen of handling this is to link to have options for some depth to be included
> * Any circular, or deep relationships should be a "link" object of some sort that points to the resource if needed
>
> How to handle binary data?
> * Blobs can be hashed, and sent as is, but would likely need a header/mimetype
>
> Explicit class schemas or schemaless
> * I want to make sure we're talking about the same thing, can you explain more?
>
> How to best handle local caching + sync?
> * This would be partially based on the client, but also on the serverside.
> * For our initial impl basic local caching is fine (or we leave it to the end user for now)
> * Sync, and more advanced offline syncing can wait for phase 2 imo
>
> Provide atomic counters? (most of these libraries do)
> * Yes, we'll likely need something like this.
> * Matthias - do you have any previous experience with this requirement?
>
> Manage clients with API keys?
> * That is a common way to do this
> * We should outline the different options
>
> Other questions:
>
> Model/entity based client storage, or database replication?
>
> On Aug 31, 2012, at 2:41 PM, Jay Balunas wrote:
>
>> Hi All,
>>
>> I'm posting Glen's gist on his review of existing apis for BaaS operations - https://gist.github.com/3495006
>>
>> Any comments and feedback welcome!
>>
>> -Jay
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)redhat.com
> https://www.redhat.com/mailman/listinfo/aerogear-dev
-- qmx
12 years, 4 months
