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
Model/entity based client storage, or database replication?
On Aug 31, 2012, at 2:41 PM, Jay Balunas wrote: