<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 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 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 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><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 href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a>
<a 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 href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a 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>