<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č &lt;<a href="mailto:lukas.fryc@gmail.com" class="">lukas.fryc@gmail.com</a>&gt; 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.&nbsp;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="">&nbsp; &nbsp; &nbsp;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="">&lt;<a href="mailto:lholmqui@redhat.com" target="_blank" class="">lholmqui@redhat.com</a>&gt;</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,&nbsp; from the JS client perspective, it felt a lot like a pipe.&nbsp; In jQuery.ajax,&nbsp; 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...&nbsp; &nbsp;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.&nbsp; This is were all the "conflict resolution happens”.&nbsp; (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,&nbsp; 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>