[aerogear-dev] Suggestion for DataSync roadmap

Mon Sep 1 03:35:25 EDT 2014

We updated the DataSync roadmap branch [1]. Again if you don't want to
build it you might be able to see it on this OpenShift instance[2] (ping me
if it's down).

We have merged the two of initial version of "conflict resolution" as they
did not really contain very much in and by themselves in reality, and we
might have most of the functionality for the first version already (perhaps
hidden in the current Pipes concepts).

The roadmap currently contains a "conflict resolution" part, and a "data
sync" part. This is inline with what we discussed at the f2f to start
simple and evolve in a step by step manner. At that time we were thinking
in terms of a message format that must be able to be evolve over time.

At the moment, in the "conflict resolution" suggestion we are not forcing
any data format and instead the developer will use whatever message/data
format they already have, with the only requirement that the server side
can detect conflicts.  When conflict is detected the server will reply with
a 409 and the body must contain the latest version of the object/document
that the server has. This would be the only change that is required on the
server side and it would not have to be updated to return any specific
message format that we define.

This also brings up what others have previously pointed out that this is
not "data sync", and perhaps we should keep these completely different.
Should we keep these separate each with it's own roadmap, spec, jira, and
releases?
Do we think that there are users that would be interested in using only the
"conflict resolution" version, and some that are only interested in the
"data sync" version is really what we are asking I guess.

Regarding offline support, for the "conflict resolution" version our
current thinking is that we would not support it in the client libraries. A
client application could support offline work itself with this version
though, for example allowing information to be updated and when a network
connection is available it would send the updates to the server which in
case of a conflict would take the actions as described above.
But for the "data sync" version it would be supported and updates (really
diffs or operations on the document/object) would be queued up and later
sent to the server to be applied.

Please let us know if you have questions or different views/ideas on
anything here!

[1]
https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap
[2]
http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/

On 25 August 2014 14:47, Daniel Bevenius <daniel.bevenius at gmail.com> wrote:

> >The main architectural point I'm missing here is whether AeroGear sync
> server should be primarily at the end:
> >1) standalone storage mechanism with data sync capability (such as
> CouchDB)
> >CLIENT <--> DATA SYNC SERVER
> >2) mediator for synchronization with <pluggable> storage mechanism
> >CLIENT <--> DATA SYNC SERVER <--> STORE (pluggable)
> >And here pluggable storage mechanism could be JAX-RS server with
> interceptors, LiveOak server, MongoDB or CouchDB...
> I'l like to see this done using option 2 in your list above.
>
>
> >Just one more question, how are these documents up to date?
> >http://aerogear.org/docs/specs/aerogear-sync-client-api/
> >http://aerogear.org/docs/specs/aerogear-sync-server-api/
> No sorry, these are have not been updated only the roadmap and minor
> spelling corrections have been done to the DataSync spec page at this
> stage.
>
>
> On 25 August 2014 14:40, Lukáš Fryč <lukas.fryc at gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Aug 25, 2014 at 12:39 PM, Daniel Bevenius <
>> daniel.bevenius at gmail.com> wrote:
>>
>>> >I expect in the mean time we should also play with prototypes and
>>> figure out what approaches fit best the needs,
>>> > and evaluate that functionally and performance-wise on sample apps.
>>> Yeah, we should definitely do that and especially with the later version
>>> as we still don't know the exact direction there.
>>>
>>> >Something what I'm missing is more comprehensive elaboration / insight
>>> in what are the target use cases and requirements on final architecture:
>>> Yeah, we should probably have some links from the road map to a page
>>> that elaborates more on these. I thought having too much in the road map
>>> would not be very nice but rather keep it pretty simple. We already have
>>> some information in the Specifications section [1] and perhaps that is the
>>> correct place to add such details and then link to them from the roadmap.
>>> What do you (all) think?
>>>
>>>
>> +1 for linking them (I didn't notice that page, my bad, and good summary
>> btw)
>>
>>
>>> >* integrate /w any general REST interface (compliant with given
>>> limitations)
>>> For the first stage we're thinking that the only requirement would be
>>> that the server can detect a conflict and return a 409 accompanied with the
>>> latest version of that the server has. This is what was discussed at the
>>> f2f and which Erik has a Forge plugin to generate.
>>> But the "real" data sync version will have much more impact on the
>>> backend and it would have to follow an application protocol that we define.
>>>
>>> >HATEOAS-compliant backend?
>>> Does this differ from the REST interface describe above now that some
>>> background information was provided?
>>> If it does that it would be great to either gather them here or that we
>>> add to aerogear.org. I'll push the branch to master so we can all work
>>> off it.
>>>
>>> > generic JAX-RS?
>>> Not sure about this, but would Erik's Forge plugin take care the generic
>>> JAX-RS backend case. Users would not need to use Forge if they choose not
>>> to, and we should document the requirements upon the backend like described
>>> in the first version. Again, if there are things we've missed then please
>>> add them.
>>>
>>
>> The main architectural point I'm missing here is whether AeroGear sync
>> server should be primarily at the end:
>>
>>
>> 1) standalone storage mechanism with data sync capability (such as
>> CouchDB)
>>
>> CLIENT <--> DATA SYNC SERVER
>>
>>
>>
>> 2) mediator for synchronization with <pluggable> storage mechanism
>>
>> CLIENT <--> DATA SYNC SERVER <--> STORE (pluggable)
>>
>> And here pluggable storage mechanism could be JAX-RS server with
>> interceptors, LiveOak server, MongoDB or CouchDB...
>>
>>
>>
>> The proposals that I've seen (and I apologize if I've missed something)
>> talk about synchronization protocol (DS, OT), conflict resolution and means
>> of communication (request/response, realtime),
>> but doesn't talk about restrictions on backend architecture. And this I
>> guess applies to 0.2, 0.3 and 0.4 versions as on the Roadmap.
>>
>>
>>
>> Just one more question, how are these documents up to date?
>>
>> http://aerogear.org/docs/specs/aerogear-sync-client-api/
>> http://aerogear.org/docs/specs/aerogear-sync-server-api/
>>
>> Is it something that fully reflects current implementation state / plans?
>>
>>
>>>
>>> >*Use cases / end-user stories:*
>>> These could be added to the existing use cases I think. See the last
>>> section of [1].
>>>
>>> Thanks for comments and the link to that document, I'll read through it.
>>>
>>>
>>> [1] http://diy-dbevenius.rhcloud.com/docs/specs/aerogear-data-sync/
>>>
>>>
>>> On 25 August 2014 11:20, Lukáš Fryč <lukas.fryc at gmail.com> wrote:
>>>
>>>> Hey Dan,
>>>>
>>>> this sounds good.
>>>>
>>>> I expect in the mean time we should also play with prototypes and
>>>> figure out what approaches fit best the needs,
>>>> and evaluate that functionally and performance-wise on sample apps.
>>>>
>>>>
>>>>
>>>> Something what I'm missing is more comprehensive elaboration / insight
>>>> in what are the target use cases and requirements on final architecture:
>>>>
>>>> *Requirements:*
>>>>
>>>> * integrate /w any general REST interface (compliant with given
>>>> limitations)
>>>> ** HATEOAS-compliant backend?
>>>> ** generic JAX-RS?
>>>> * integrate seamlessly with LiveOak
>>>>
>>>> *Use cases / end-user stories:*
>>>>
>>>> * mobile sales client
>>>> * mobile warehouse manager
>>>> * delivery agent
>>>>
>>>> Inspiration:
>>>> https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit
>>>>
>>>>
>>>> I expect we target different use cases in different phases.
>>>> So we could indicate what use cases are valid in what phase.
>>>>
>>>> Should we brainstorm this on wiki or so?
>>>>
>>>>
>>>> Cheers!
>>>>
>>>> ~ Lukas
>>>>
>>>>
>>>>
>>>> On Mon, Aug 25, 2014 at 9:58 AM, Daniel Bevenius <
>>>> daniel.bevenius at gmail.com> wrote:
>>>>
>>>>> >is Nov, 2014, right?
>>>>> Yep, sorry that should be 2015. I'll correct that. Thx
>>>>>
>>>>>
>>>>> On 25 August 2014 09:57, Matthias Wessendorf <matzew at apache.org>
>>>>> wrote:
>>>>>
>>>>>> 0.2.0 (Nov, 2015) Conflict resolvers
>>>>>> is Nov, 2014, right?
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius <
>>>>>> daniel.bevenius at gmail.com> wrote:
>>>>>>
>>>>>>> We have been working on a roadmap for DataSync to help our planning
>>>>>>> of the features and time frames.
>>>>>>>
>>>>>>> A suggestion for the roadmap can be found in this branch:
>>>>>>>
>>>>>>> https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap
>>>>>>>
>>>>>>> If you don't feel like building it yourself you can try this
>>>>>>> OpenShift instance:
>>>>>>>
>>>>>>> http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/
>>>>>>>
>>>>>>> Please note that the dates are just made up and something that we
>>>>>>> need help from each client library project to provide feedback on what is
>>>>>>> reasonable.
>>>>>>>
>>>>>>> Let us know what you think and from the feedback given, either here
>>>>>>> or as PRs, we will try to break this down further and start creating JIRAs
>>>>>>> to link to the roadmap.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/c41b9507/attachment-0001.html 