[aerogear-dev] Concerns on JS Conflict Resolution lib

Lucas Holmquist lholmqui at redhat.com
Tue Dec 16 08:39:26 EST 2014


> On Dec 16, 2014, at 6:41 AM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
> my understand was that the main focus is now on the real-time sync, leveraging out differential synchronization engine. 

i was not aware of that.  I was under the understanding that both would be done in parallel since conflict resolution might be the solution for many people


> 
> This reflects also the current move of removing the 'rest sync' module
> https://github.com/aerogear/aerogear-sync-server/commit/5fe0b240d646ef57c5927f726c6bf2c04aa5d3cc <https://github.com/aerogear/aerogear-sync-server/commit/5fe0b240d646ef57c5927f726c6bf2c04aa5d3cc> 
> 
> -Matthias
> 
> On Mon, Dec 15, 2014 at 5:31 PM, Lucas Holmquist <lholmqui at redhat.com <mailto:lholmqui at redhat.com>> wrote:
> So i have some concerns on the Current state of the conflit resolution POC that i created.
> 
> in it's current state, i had 3 methods in the api
> 
> * Read - just a GET
> * Save - PUT/POST with an added "conflict" callback to handle the conflict resolution
> * Remove - just a DELETE
> 
> This was all done before we wrote this spec
> 
> https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/ <https://aerogear.org/docs/planning/roadmaps/AeroGearConflictResolution/>
> 
> 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".
> 
> 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.
> 
> 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...)
> 
> I think it would be interesting to try to integrate this part into existing frameworks, rather than trying to create Pipeline again.
> 
> 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
> 
> 
> Again, this might only be a concern on the JS client side,  not sure what the other platforms are like in this regard
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
> 
> -- 
> Matthias Wessendorf 
> 
> blog: http://matthiaswessendorf.wordpress.com/ <http://matthiaswessendorf.wordpress.com/>
> sessions: http://www.slideshare.net/mwessendorf <http://www.slideshare.net/mwessendorf>
> twitter: http://twitter.com/mwessendorf <http://twitter.com/mwessendorf>_______________________________________________
> 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/20141216/4bb19a6c/attachment.html 


More information about the aerogear-dev mailing list