<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">At a minimum, the same HTTP error codes used to indicate "sync errors" via JAX-RS + JPA should be the same for LiveOak's REST APIs - therefore the client-code can be reusable across the two endpoints. We should come up with sync strategies - levels 1, 2 and 3 - where 1 is simply the clever use of HTTP error codes and level 3 is real-time/off-line/auto-conflict resolution. Perhaps there are 4 levels :-)<div><br></div><div>Anyone care to articulate the possible strategies?<br><div><br><div><br><div><div>On Jul 8, 2014, at 9:02 AM, Summers Pittman <<a href="mailto:supittma@redhat.com">supittma@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote:<br><blockquote type="cite"><br>Initial email to get some discussion going around the LiveOak SDK and<br>AeroGear collaboration.<br><br>Essentially in LiveOak we are going to need a few different SDK types<br><br>- Client Application SDK<br>This is the code which will run on the users device. Initial targets<br>here are javascript (+ cordova support), iOS, Android. This type of SDK<br>will handle things like getting and sending resources to and from the<br>server, handling login/logout/registration, etc. Probably some other<br>things like device registration would be needed as well.<br><br>Not sure if we want to provide support for some other things outside of<br>communicating with the server or not (eg access to device components (eg<br>camera, location, etc)) or if these would be best handled by using the<br>native environment's SDK instead.<br><br>- Server Side SDK<br>This is code that runs on the server side, written in JavaScript by the<br>application developer. This will need to be familiar to the client<br>application's JavaScript SDK, but may not be exactly the same. This type<br>of SDK will be able to access the same resources as the client side<br>JavaScript, as well as other internal resources and libraries.<br><br><br>I am not sure how to collaborate between the LiveOak and AeroGear teams<br>here. AeroGear makes really awesome SDKs for various mobile platforms,<br>but with LiveOak we are dealing with a specific type of application. The<br>AeroGear SDKs tend to handle the more generic case, which I don't<br>necessarily think makes sense for a LiveOak SDK.<br><br>I do think it makes sense that the LiveOak SDK uses the AeroGear SDK<br>internally, but I don't know if we want to expose these AeroGear<br>components to a LiveOak developer or not.<br><br><br>For me, I envision something like the admin setting up their application<br>in the LiveOak console which then generates a json configuration file<br>(url locations, resources available, KeyCloak settings, UPS settings,<br>etc). The application developer then drops this json file in to their<br>application, the LiveOak SDK reads the json file to set it self up and<br>then its really easy for the developer to start using it.<br><br>[there are also some really cool things we could be doing here as well<br>if we can get awesome data sync support for AeroGear. It might be<br>interesting to be able to fetch a resource from the server and<br>automatically sync its state across between the client and server. This<br>way the object appears as a local object: if the resource changes on the<br>server, it changes locally as well, if it changes locally, that change<br>is pushed to the server. This way you are just dealing with an object,<br>and not having to fetch and then push object back and forth between the<br>server manually]<br><br>Anyone have any thoughts on this?<br></blockquote><br>One of the things which may be useful is aerogear-ios and<span class="Apple-converted-space"> </span><br>aerogear-android are both modularizing their libraries. IN theory this<span class="Apple-converted-space"> </span><br>means that the liveOAK SDK's could be extensions of those modules<span class="Apple-converted-space"> </span><br>instead of a single monolothic thing.<br><br>Sync is still an ongoing discussion in AeroGear, but I think right now<span class="Apple-converted-space"> </span><br>the current group thought is that we will focus on 409 Conflict events<span class="Apple-converted-space"> </span><br>(JPA versioning on server side and utilities on the client side) and not<span class="Apple-converted-space"> </span><br>worrying about realtime sync.<br><br><br>Some notes from out last meeting on the topic :<br>Client API Strawman :<br><a href="https://github.com/secondsun/aerogear-android-sync/tree/master/android">https://github.com/secondsun/aerogear-android-sync/tree/master/android</a><br>Client/Server workflow :<br><a href="https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit">https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit</a><span class="Apple-converted-space"> </span><br><br><br>Also we are looking at doing something with diff merge patch as well as<span class="Apple-converted-space"> </span><br>adding in push based data changed notifications later.<br><br><br><blockquote type="cite">_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote><br><br><br>--<span class="Apple-converted-space"> </span><br>Summers Pittman<br><blockquote type="cite"><blockquote type="cite">Phone:404 941 4698<br>Java is my crack.<br></blockquote></blockquote><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></div></blockquote></div><br></div></div></div></body></html>