[aerogear-dev] Suggestion for DataSync roadmap

Daniel Bevenius daniel.bevenius at gmail.com
Mon Aug 25 08:47:47 EDT 2014


>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/20140825/d280c65f/attachment-0001.html 


More information about the aerogear-dev mailing list