extended roadmap by Partial Updates, SPDY and Batch API

[lfryc]

Added:

• Dec 2014
  • Partial Updates
  • SPDY
• Jan 2015
  • Batch API

Rendered version: https://github.com/lfryc/aerogear.org/blob/partial-updates-spdy-batches/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc#020-dec-2014-server-push-partial-updates

[danbev]

@lfryc I was wondering if we should keep the 0.2.0 milestone to include the 'Server Push' that is in the current version:
https://github.com/aerogear/aerogear.org/blob/data-sync-rebirth-roadmap/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc#020-jan-2015-server-push

We could begin with the updates you made in this PR starting from 0.3.0. Wdyt?

[lfryc]

Looking again at the roadmap I've noticed I forgot to mention Offline/Persistence feature, that should be also implemented early on, what about:

@danbev sounds good to me. Are you fine with:

• Dec 2014
  • Server Push
  • Persistence / Offline (needs to be mentioned in roadmap)
• Jan 2015
  • Partial Updates
  • SPDY
• Mar 2015
  • Batch API

I'm little bit worried here that SPDY may actually inhibit need for Batch API dramatically, that's why I moved it to later dates.

[lfryc]

Looking again at the roadmap I've noticed I forgot to mention Offline/Persistence feature, that should be also implemented early on.

[danbev]

@lfryc Sounds good with the dates. We can revisit them later on when we have a clearer picture.
Yeah, I see you point with the requirements but lets see what the others say. We could leave it a little more open or just change it later if run into roadblocks.
I also forgot to bring up Offline/Persistence. This was something that Luke and I discussed before and that it would definitely be something we provide for the "real-time" stuff but perhaps not for the simpler two milestones.

[lfryc]

yea, I was rather considering extending features of simpler solution by even Offline/Persistence, because simpler solution (as opposed to realtime) offers stateless functionality.

[lfryc]

I've added Offline/Persistence and moved with dates of Server Push, SPDY and Batch API.

What you think now?

[danbev]

@lfryc I was thinking that the 0.2.0 to be a minor update to 0.1.0 like it was before, and only add notifications that a new version is available. Basically what you have but without the partial updates. That would come with the next milestone. I think the 0.2.0 milestone might be enough for some use cases and it would make it clear that there are no additional server side requirements for that 0.2.0. After this we can introduce the more advanced partial updates which require changes to the server side.

I like the other updates you've made. Nice work!

[danbev]

@lfryc I can create a PR against your branch with a suggestion if you like, might be easier to se what I'm on about?

[lfryc]

yes, please, go ahead @danbev :-)

[lfryc]

merged PR from @danbev : lfryc#1

[sebastienblanc]

Looks good ! I like the "progressive enhancement" in features along the releases.
Some questions about the clients ? Where will that be implemented ? In the Pipes Modules (for Android and JS) and ios-http (for iOS) ? Or in a new Module ?
What about Cordova ? Will we able to use the JS impl or would a plugin be needed ?

[danbev]

What about Cordova ? Will we able to use the JS impl or would a plugin be
needed ?
Good point. I was thinking that Cordova would be able to use the JS impl,
but if that is not the case then let us know and we'll add tasks for a
Cordova plugin as well.

On 11 September 2014 13:35, Sebastien Blanc notifications@github.com
wrote:

Looks good ! I like the "progressive enhancement" in features along the
releases.
Some questions about the clients ? Where will that be implemented ? In the
Pipes Modules (for Android and JS) and ios-http (for iOS) ? Or in a new
Module ?
What about Cordova ? Will we able to use the JS impl or would a plugin be
needed ?

—
Reply to this email directly or view it on GitHub
#386 (comment).

[corinnekrych]

@danbev @lfryc for 0.4.0 when you talk about offline support does it include secure offline support? offline support for sensitive data that might need encryption.

[danbev]

@corinnekrych It certainly can include encryption I think, and we should perhaps state this explicitly.

[corinnekrych]

@danbev yeap i think it deserves a mention by itself.
Besides you've got dependency on AGSEC-12 - offline authentication
tbh I'd split the 2: offline vs secure offline.

[lfryc]

Where will that be implemented ? In the Pipes Modules (for Android and JS) and ios-http (for iOS) ? Or in a new Module ?

The roadmap intentionally doesn't talk much about Client SDK APIs, because the way the features are implemented might be platform dependent. Each of the platform teams should IMO investigate what is the best approach. For JS, I believe Pipes should be our first-class citizen, but support for other modules (Angular Data, Ember Data) should be evaluated as well. It would be probably good to add a note about it in roadmap if you agree ^

does it include secure offline support?

Yes, we could add Offline support and Authentication as well. Just an idea: what about leaving Secure Offline vs. Data Persistence / Offline as two separated concerns? We can still mention here there is a dependency.

[lfryc]

too late to the party as @corinnekrych already suggested split of Offline / Secure Offline :-)

[lholmquist]

i thought pipes were going away?

[danbev]

what about leaving Secure >Offline vs. Data Persistence / Offline as two separated concerns?

@lfryc Sounds good to me

[lfryc]

@lholmquist you are right, as always :-) the question is whether this will be part of AG.js 1.x or 2.0, but for that we could probably hold a JS meeting

[lholmquist]

@lfryc sounds good

[lfryc]

Any comments or concerns before merging this?

@danielpassos @secondsun sounds good from Android's front perspective?

[danielpassos]

I like that. Sounds good for me

[secondsun]

👍

[lfryc]

Thanks, guys, for review!

[lfryc]

Merged to data-sync-rebirth-roadmap