<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 12/10/2013 11:16 AM, Sebastien Blanc
wrote:<br>
</div>
<blockquote
cite="mid:CAD_dpu1CVDdmtvXdpktS44kv9qRNsb1hj8MR7WCLuwZKOfZ8mg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Dec 10, 2013 at 4:13 PM,
Summers Pittman <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:supittma@redhat.com"
target="_blank">supittma@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="im">
<div>On 12/10/2013 02:34 AM, Erik Jan de Wit wrote:<br>
</div>
<blockquote type="cite">
<div><br>
</div>
<div>
<div>On 9 Dec,2013, at 17:06 , Summers Pittman
<<a moz-do-not-send="true"
href="mailto:supittma@redhat.com"
target="_blank">supittma@redhat.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> For real
time sync this is a great primer: <a
moz-do-not-send="true"
href="https://neil.fraser.name/writing/sync/"
target="_blank">https://neil.fraser.name/writing/sync/</a>.
The concepts can be expanded beyond text of
course.<br>
</div>
</blockquote>
<div><br>
</div>
<div>That is a great article, but all these
techniques are only cool for documents. </div>
</div>
</blockquote>
</div>
This technique is good for synced text. We've hooked
our horse to the JSON cart pretty hard so we should be
able to deal with that for a large number of cases.
<div class="im">
<blockquote type="cite">
<div>
<div>We could support documents of course, but I
was thinking more about Pipes and syncing those
when one has been offline for a while. </div>
</div>
</blockquote>
</div>
So Pipes aren't data per se. They are a one way query
mechanism (IE the pipe doesn't start spewing data all
over your living room floor for no reason.) Pipes can
be used by Sync to fetch data once a signal to refresh
has been received however.
<div class="im"><br>
<blockquote type="cite">
<div>
<div>So for example when you have a Car that has
make <span
style="line-height:16px;font-size:13px;font-family:'Helvetica
Neue',Helvetica,Arial,san-serif">Toyota</span> and
one changes it to <span
style="line-height:16px;font-size:13px;font-family:'Helvetica
Neue',Helvetica,Arial,san-serif">Toiota</span> and
another changes it <span
style="line-height:16px;font-size:13px;font-family:'Helvetica
Neue',Helvetica,Arial,san-serif">Toyotas
merging these to changes to </span><span
style="line-height:16px;font-size:13px;font-family:'Helvetica
Neue',Helvetica,Arial,san-serif">Toiota</span>s
is always wrong. We don’t need merge support we
only need conflict resolution.</div>
</div>
</blockquote>
</div>
'<span
style="line-height:16px;font-size:13px;font-family:'Helvetica
Neue',Helvetica,Arial,san-serif"></span><span
style="line-height:16px;font-size:13px;font-family:'Helvetica
Neue',Helvetica,Arial,san-serif">Toiota</span>s' Yes,
'Toiotas' (no cap) no. That would actually be correct
in patch diff merge.</div>
</blockquote>
<div>What's the difference between these 2 ? <br>
</div>
<div>Bu the point of Erik was that we don't want this kind
of merge, no ? <br>
</div>
</div>
</div>
</div>
</blockquote>
The difference is we have different opinions, use cases, and ideas
of "correct". Our users will also have said ideas so our solution
should make it possible for both to be supported (even if we only
provide one).<br>
<br>
<blockquote
cite="mid:CAD_dpu1CVDdmtvXdpktS44kv9qRNsb1hj8MR7WCLuwZKOfZ8mg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="im"><br>
<br>
<blockquote type="cite">
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
I guess my question is do we want a really low
level but universal protocol which requires
server support, or several separate APIs which
can handle legacy servers, servers with minor
changes, or real time capable servers?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Cool idea to connect a legacy backend and let
the front-end deal with the sync. But we can’t
support conflict resolution in this scenario. </div>
</div>
</blockquote>
</div>
We can limit legacy servers to read only data (from a
client perspective).
<div class="im"><br>
<blockquote type="cite">
<div>
<div>For example client1 and client2 change the
same car object. Client1 changes the property
colour from red to green and client2 changes it
from red to blue. The change of client1 takes
place first then the change of client2 will be a
conflict. Now to detect that conflict we could
fetch the entity again and check if the colour
is still the same as our original value, but it
could change in the mean time again. So there is
no guarantee that the data will be consistent.</div>
<div><br>
</div>
<div>Of course we could periodically fetch data
from a legacy server and merge that with the
client state, but I don’t think that this is
super useful the power of sync is changing
things to be able to work offline. </div>
</div>
</blockquote>
<br>
</div>
Of course, offline is just laggy sync. <br>
<br>
But lets take two separate but similar legacy use
cases. Downloading the weather forecast based on your
location and synchronizing a todo list.<br>
<br>
The weather data probably won't change during the day.
So every night at midnight + jitter our sync can
download the forecast from a restful URL and be done.
There is no conflict because the client data can not /
will not change. This is a very simple case to
implement.<br>
<br>
Syncing a Todo list is more complicated because it can
change from multiple clients. HOWEVER the application
has a restriction that todo list items may only be added
and removed but not reordered or edited.<br>
<br>
The flow for that could look like<br>
<br>
1. User 1 on Android creates a TODO list.<br>
2. Android app creates TODO list copy on server.<br>
3. Android app registers a sync with the server for the
todo list<br>
4. User 1 adds item to TODO list.<br>
5. Server syncs its list with Users list. returns OK.<br>
6. User 1 access his list in web app.<br>
7. Web App registers a sync on the server with the todo
list.<br>
8. User 1 Edits his list.<br>
9. Web App applies edits and sends deltas to Android
app.<br>
10. repeate ad nausiem.<br>
<br>
In this case conflicts can only happen if a user deletes
the same item (no practical conflict). So a conflict
resolver will be trivial.
<div class="im"><br>
<br>
<blockquote type="cite">
<div>
<div>So I think we need a protocol, can be really
simple just versioned JSON, and a server that
will compare the changes and return conflicts.</div>
</div>
</blockquote>
</div>
Yeah. The more I poke and play with things the less
certain I am that adding it to the pipe is a good idea.
I think we need something separate.<br>
<blockquote type="cite">
<div class="im">
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> <br>
As examples:<br>
Legacy Servers can be periodic pollers.<br>
Minor changes can be a sync on push type
thing.<br>
And realtime, is well, real time.<br>
<br>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
</div>
<div class="im">
<pre>_______________________________________________
aerogear-dev mailing list
<a moz-do-not-send="true" href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</div>
</blockquote>
<br>
</div>
<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"
target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
</body>
</html>