<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 16, 2014, at 4:22 AM, Lukáš Fryč <<a href="mailto:lukas.fryc@gmail.com" class="">lukas.fryc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hey Luke,<div class=""><br class=""></div><div class="">That seems sensible. I'm glad you are questioning this at the very beginning.<div class=""><br class=""><div class="">JS conflict resolution in my eyes makes sense if we build some kind of ORM or three-way binding solution (we'd obviously create just client-model-to-server-model binding part, the rest is up to the MVC framework).</div><div class=""><br class=""></div><div class="">I also believe that Conflict Resolution API shouldn't be much different from our Realtime sync from the API standpoint,</div><div class="">the real difference is that Conflict Resolution can easily intergrate with existing concepts and backends because of its RESTful nature,</div><div class="">while Realtime sync requires special backend handling (aka sync-server):</div><div class=""><br class=""></div><div class=""> Sync.save(objectInstance);</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Additionally, Conflict Resolution has points on the roadmap that goes far behind regular framework principles: Partial Updates, Batch Updates, Server Notifications...</div><div class=""><br class=""></div><div class="">As discussed on F2F, we should though always think about how this integrates into wider picture (existing frameworks).</div><div class=""><br class=""></div><div class="">For this moment, we could start just with examples, they could also demonstrate us what deficiencies existing solutions have.<br class=""></div></div><div class="">And if nothing, the only deliverable for conflict resolution at the end maybe a cookbook, a doc/guide and maybe some contributions to upstream :-)</div></div></div></div></blockquote><div>this might be a good start</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Dec 15, 2014 at 5:31 PM, Lucas Holmquist <span dir="ltr" class=""><<a href="mailto:lholmqui@redhat.com" target="_blank" class="">lholmqui@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So i have some concerns on the Current state of the conflit resolution POC that i created.<br class="">
<br class="">
in it's current state, i had 3 methods in the api<br class="">
<br class="">
* Read - just a GET<br class="">
* Save - PUT/POST with an added "conflict" callback to handle the conflict resolution<br class="">
* Remove - just a DELETE<br class="">
<br class="">
This was all done before we wrote this spec<br class="">
<br class="">
<a href="https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/" target="_blank" class="">https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/</a><br class="">
<br class="">
but even then, from the JS client perspective, it felt a lot like a pipe. In jQuery.ajax, you can actually listen for a "409".<br class="">
<br class="">
The other thing that concerns me is that on the client side, people are using frameworks such as Ember, Angular, Backbone,etc... that have there own ways of doing server requests so i would hate to start re-inveting the wheel again.<br class="">
<br class="">
while the read/remove don't really do anything different(they are just GET/DELETE's), the save method(PUT/POST) does. This is were all the "conflict resolution happens”. (what type on resolution algorithm, auto-merge, etc...)<br class="">
<br class="">
I think it would be interesting to try to integrate this part into existing frameworks, rather than trying to create Pipeline again.<br class="">
<br class="">
i think for node.js this might be interesting too, since we could create a piece of middleware that hooks into an express/connect request<br class="">
<br class="">
<br class="">
Again, this might only be a concern on the JS client side, not sure what the other platforms are like in this regard<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
aerogear-dev mailing list<br class="">
<a href="mailto:aerogear-dev@lists.jboss.org" class="">aerogear-dev@lists.jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote></div></div>
_______________________________________________<br class="">aerogear-dev mailing list<br class=""><a href="mailto:aerogear-dev@lists.jboss.org" class="">aerogear-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/aerogear-dev</div></blockquote></div><br class=""></body></html>