<div dir="ltr">Sorry forgot this one...<div><br><div>><span style="font-family:arial,sans-serif;font-size:13px">integrate seamlessly with LiveOak</span></div><div><font face="arial, sans-serif">For the first versions where there is only the requirement to detect conflicts and return the latest version, this would have to be implemented in LiveOak. </font></div>
<div><font face="arial, sans-serif">For the later version the way I see it would be similar to how the experimental differential synchronization (DS) server is "embedded" in a Netty server [1]. Instead of running it in a Netty server it would be run inside of LiveOak and they could hook it up with there storage. Note sure if this will actually work but at least that is the idea. </font><span style="font-family:arial,sans-serif">I know that DS not be the path we choose, but perhaps a similar approach could be used for the actual server later on.</span></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">[1] <a href="https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/diffsync/server-netty">https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/diffsync/server-netty</a></font></div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 August 2014 12:39, Daniel Bevenius <span dir="ltr"><<a href="mailto:daniel.bevenius@gmail.com" target="_blank">daniel.bevenius@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="">><span style="font-family:arial,sans-serif;font-size:13px">I expect in the mean time we should also play with prototypes and figure out what approaches fit best the needs,</span><div style="font-family:arial,sans-serif;font-size:13px">
> and evaluate that functionally and performance-wise on sample apps.</div></div><div style="font-family:arial,sans-serif;font-size:13px">Yeah, we should definitely do that and especially with the later version as we still don't know the exact direction there. </div>
<div class="">
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">>Something what I'm missing is more comprehensive elaboration / insight in what are the target use cases and requirements on final architecture:</div>
</div><div>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?</div>
<div class="">
<div><br></div><div>><span style="font-family:arial,sans-serif;font-size:13px">* integrate /w any general REST interface (compliant with given limitations)</span></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">For the first stage we're</span><span style="font-family:arial,sans-serif;font-size:13px"> 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. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">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. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">HATEOAS-compliant backend?</span></div>
<div><font face="arial, sans-serif">Does this differ from the REST interface describe above now that some background information was provided? </font></div><div><font face="arial, sans-serif">If it does that it would be great to either gather them here or that we add to <a href="http://aerogear.org" target="_blank">aerogear.org</a>. I'll push the branch to master so we can all work off it. </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">></font><span style="font-family:arial,sans-serif;font-size:13px"> </span><span style="font-family:arial,sans-serif;font-size:13px">generic JAX-RS?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div class="">
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">></span><b style="font-size:13px;font-family:arial,sans-serif">Use cases / end-user stories:</b></div>
</div><div><font face="arial, sans-serif">These could be added to the existing use cases I think. See the last section of [1]. </font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Thanks for comments and the link to that document, I'll read through it. </font></div>
<div><br></div><div><br></div><div>[1] <a href="http://diy-dbevenius.rhcloud.com/docs/specs/aerogear-data-sync/" target="_blank">http://diy-dbevenius.rhcloud.com/docs/specs/aerogear-data-sync/</a></div></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra"><br>
<br><div class="gmail_quote">On 25 August 2014 11:20, Lukáš Fryč <span dir="ltr"><<a href="mailto:lukas.fryc@gmail.com" target="_blank">lukas.fryc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hey Dan,<div><br></div><div>this sounds good.</div><div><br></div><div>I expect in the mean time we should also play with prototypes and figure out what approaches fit best the needs,</div><div>and evaluate that functionally and performance-wise on sample apps.</div>
<div><br></div><div><br></div><div><br></div><div>Something what I'm missing is more comprehensive elaboration / insight in what are the target use cases and requirements on final architecture:</div><div><br></div><div>
<div><b>Requirements:</b></div><div><br></div><div>* integrate /w any general REST interface (compliant with given limitations)</div><div>** HATEOAS-compliant backend?</div><div>** generic JAX-RS?</div><div>* integrate seamlessly with LiveOak</div>
</div><div><br></div><div><b>Use cases / end-user stories:</b></div><div><br></div><div>* mobile sales client</div><div>* mobile warehouse manager</div><div>* delivery agent</div><div><br></div><div>Inspiration: <a href="https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit" target="_blank">https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit</a></div>
<div><br></div><div><br></div><div>I expect we target different use cases in different phases.<br></div><div>So we could indicate what use cases are valid in what phase.<br></div><div><br></div><div>Should we brainstorm this on wiki or so?</div>
<div><br></div><div><br></div><div>Cheers!</div><div><br></div><div>~ Lukas</div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 9:58 AM, Daniel Bevenius <span dir="ltr"><<a href="mailto:daniel.bevenius@gmail.com" target="_blank">daniel.bevenius@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">><span style="font-family:arial,sans-serif;font-size:13px">is Nov, 2014, right? </span><div><span style="font-family:arial,sans-serif;font-size:13px">Yep, sorry that should be 2015. I'll correct that. Thx</span></div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 August 2014 09:57, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><h3 style="font-size:1.25em;margin:1em 0px;color:rgb(226,80,39);letter-spacing:-1px;font-family:'Open Sans',sans-serif">
0.2.0 (Nov, 2015) Conflict resolvers</h3>
<div>is Nov, 2014, right? </div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius <span dir="ltr"><<a href="mailto:daniel.bevenius@gmail.com" target="_blank">daniel.bevenius@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">We have been working on a roadmap for DataSync to help our planning of the features and time frames.<div>
<div>A suggestion for the roadmap can be found in this branch:</div><div><a href="https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap" target="_blank">https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap</a><br>
</div><div><br></div><div>If you don't feel like building it yourself you can try this OpenShift instance:</div><div><a href="http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/" target="_blank">http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/</a></div>
<div><br></div><div>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. </div><div><br></div><div>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. </div>
<div><br></div><div><br></div></div></div>
<br></div></div>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><span><font color="#888888"><br></font></span></blockquote></div><span><font color="#888888"><br>
<br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br>
<br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</font></span></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>