[aerogear-dev] Suggestion for DataSync roadmap

Mon Aug 25 08:40:19 EDT 2014

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/e15f1974/attachment.html 