<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/07/14 09:11 AM, Burr Sutter
wrote:<br>
</div>
<blockquote
cite="mid:1FDBF7E3-69D5-4C65-88F4-18A8416FEBC2@redhat.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
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>
</blockquote>
<br>
Some thoughts:<br>
<br>
1) No conflict resolution. The way it handled in LiveOak right now,
whoever is the last person to push to the server overwrites any
other changes. Obviously not ideal, but may be acceptable in some
cases. (or enabled via a 'force' option)b<br>
<br>
2) Only allowed to update from the latest version: only allow
updates if the resource being updated has not already been modified
by someone else. If it has been updated, return HTTP error code<br>
<br>
3) Non-conflicting field updates allowed: allow partial,
non-conflicting updates to fields; otherwise return HTTP error code
(Eg userA & userB both fetch resourceA from the server, userA
makes a change to the 'foo' field and pushes it to the server. UserB
makes a change to the 'bar' field and tries to push to the server.
Since its a change to a different field, it is allowed).<br>
<br>
4) Non-conflicting updates allowed: expands on the non-conflicting
field updates. A smarter diff type system where its can handle more
than just modifications to different fields. Eg say there is an
'article' field, UserA and UserB checkout the resource. UserA fixes
a typo and pushes it to the server. UserB fixes the same typo and
fixes 2 other typos. UserB can commit his change since his changes
don't conflict with the previous update.<br>
<br>
[I am sure there are probably some nice diff and merge libraries
around that we could use on the server side to take care of handling
the conflict logic]<br>
<br>
The above is all stuff which needs to be done on the server side.
And there are a few interesting things here where, except for the
first option, we could require the data on the server to include
special fields for conflict resolution (or something like a md5sum
of the resources state). Having special fields like this breaks some
data features we currently have in LiveOak, but its probably
something we can make configurable and have a compromise.<br>
<br>
Client side stuff:<br>
<br>
1) offline support: I am assuming this is about having some sort of
local data cache so that when offline we can get the cached objects.
All without having to resort to the whole fetch from a URL then save
to local storage manually. Eg liveoak.get("/foo/bar") would fetch
and cache locally if online, if offline liveoak.get("/foo/bar")
would just get it from the cache. Some interesting stuff would need
to be done here on the client side.<br>
<br>
[any plan for encryption and security in this local storage? Any
ability to wipe the cache from the console if the device is lost or
stolen?]<br>
<br>
2) real-time: this is where I think things get more interesting. If
we had conflict resolution (and partial updates) we could almost do
this already in LiveOak (eg register to receive changes to a
particular resource when modified on the server, push partial
updates when the resource is modified locally. These steps of course
would be handled by the SDK and not expected to be manually handled
by the developer). This would also tie into the offline support, so
when the device goes offline and then comes back, it would need to
be able to handle the conflicts and push results back to the server.<br>
<br>
Other considerations<br>
- exposing conflicts to the developer so they can manually handle
the issue and/or notify the user.<br>
- allowing the developer to specify what kind of conflict resolution
they want for what resources<br>
- how to configure local storage (eg only cache objects already
accessed, prefetch a list of resources, never cache certain
resources, etc....)<br>
<br>
Anything else?<br>
<br>
<br>
<blockquote
cite="mid:1FDBF7E3-69D5-4C65-88F4-18A8416FEBC2@redhat.com"
type="cite">
<div>
<div><br>
<div><br>
<div>
<div>On Jul 8, 2014, at 9:02 AM, Summers Pittman <<a
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>