<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 04/10/2013 09:30 AM, Sebastien Blanc
wrote:<br>
</div>
<blockquote
cite="mid:CAD_dpu0ZPLu+_TooT4R6Ynh3D8Tj9kayNigq72ovbuxhTQ_RJw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Apr 10, 2013 at 3:00 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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="h5">
<div>On 04/10/2013 05:23 AM, Sebastien Blanc wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Mar 27, 2013
at 7:43 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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sorry
for the questionable formatting before,
this should be more<br>
correct now.<br>
<div>
<div><br>
So for offline and sync for 2.0 I’ve
been doing some thinking/research<br>
and come up with some broad topics to
discuss so we can start honing in<br>
on what we want it to do/look like.<br>
<br>
This isn’t a spec, this isn’t a
proposal, this is just trying to
narrow<br>
down what we want at a high level so
we can pick things to focus on.<br>
<br>
1. Documents vs Transactions<br>
<br>
There are two “big picture” methods of
doing sync. One is a Document<br>
sync (Think like a gallery with videos
and pictures). Documents are<br>
saved, the whole document is sent to
the server, then the whole document<br>
is pushed out to other clients who are
syncing against the same source.<br>
The other is a Transactional sync
where many small atomic operations are<br>
sent to the server. The best analog I
have is Google Drive/operation<br>
transforms.<br>
<br>
Obviously the server side
implementations of these are
hilariously<br>
divergent and I will leave the
relative complexity of each as an<br>
exercise for the list.<br>
<br>
</div>
</div>
</blockquote>
<div>IMO, because Aerogear is a library we
should focus on a Transactional sync to
let the users a more fine-grained control.
But later, we should be able to provide
some wrappers around this atomic
operations to offer something close to
document sync (or let the users easily
define a "Document", like a view in SQL)</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div> 2. Background vs Foreground sync<br>
<br>
Does the application have to be opened
(foreground) for syncing to<br>
happen? As far as I know, native Web
requires this (barring extensions<br>
to the browser, plugins etc). I think
Cordova can in Android, but I<br>
haven’t researched it. iOS seems like
a mixed bag, but generally you can<br>
only sync if your application is in
the foreground (but you can use<br>
notifications and badges to
communicate that there is a pending
sync or<br>
new data). I understand there is
CoreData + iCloud that is supposed to<br>
do something, but that seems like it
is still foreground only. On<br>
Android background sync is easy.<br>
<br>
Is it OK to only have background
syncing on some platforms but not
others?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Shouldn't we trigger a sync only when
we go from an offline status to an online
status ? </div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
No. The only difference (conceptually) between being
online and offline is latency. <br>
<br>
If I am polling (yuck) ever 5 minutes and I am offline
for two of those minutes, I should still only poll when
my five minutes is up and am online. We don't want an
extra sync in the middle.
<div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>And sync strategy should be configurable
(both on client side and server side) <br>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div> <br>
3. Push vs Poll?<br>
<br>
Obviously pushing updates is better for
devices and users, but polling<br>
will let things work better for legacy
services which may not have push<br>
support or which may be difficult to
integrate into AG-Controller.<br>
<br>
Should we support both on the clients?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, we should promote push but have a
fallback to a pull strategy <br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
And push could lean on a NNP Notifier perhaps?
<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div> <br>
4. Multiple clients,multiple users, and
conflicts<br>
<br>
How do we want to support multiple users
and multiple clients? How<br>
should we try to do conflict resolution?
What does authorization and<br>
authentication look like here?<br>
<br>
At a high level here are some options I
have seen for conflict resolution:<br>
<br>
A. Last in always wins. The server
explicitly trusts things in the order<br>
it gets and pushes that data out to
users.<br>
<br>
B. Clients are allowed one submit at a
time and must wait for the server<br>
to acknowledge the receipt. If there is
a conflict the app can either a)<br>
merge the data, b)reload the latest from
the server and make the user do<br>
his operation again, or c) create a new
document and inform the user.<br>
<br>
C. Operation Transforms. This was meant
to solve the conflict and sync<br>
problem. However it is a LOT of work<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I would add another option :</div>
<div>E. The Strongest always win : i.e An
admin user change will always be considered
with a higher weight when merging a
conflict. <br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
Does ag-controller have an idea of privileged levels
right now?</div>
</blockquote>
<div><br>
</div>
<div style="">Yes, if combined with ag-sec :</div>
<div style=""><a moz-do-not-send="true"
href="https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/java/org/jboss/aerogear/controller/demo/Routes.java#L83">https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main/java/org/jboss/aerogear/controller/demo/Routes.java#L83</a></div>
</div>
</div>
</div>
</blockquote>
But admin is just an arbitrary identifier. I'm wondering if there
is any way to say that "admin" > "logged in" > "slacker" >
"anonymousUser". <br>
<blockquote
cite="mid:CAD_dpu0ZPLu+_TooT4R6Ynh3D8Tj9kayNigq72ovbuxhTQ_RJw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div> <br>
5. Offline Support<br>
<br>
Really this is more what do we want to
do for coming from an “offline”<br>
mode to an “online” mode? Abstractly,
operations which happen offline<br>
are the same as operations which
happen online just with a REALLY
REALLY<br>
laggy connection. :) We could just
only viewing data when offline and<br>
requiring a connection for editing,
queueing an upload, etc.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Ideally, we should be able to provide
the same functionality no matter we are
online or offline. For example, when I'm
in the middle of the ocean, I still want
to be able to tag my Dolphins ;) </div>
<div>But we could think about "degraded
service levels" ... </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div> <br>
6. How much of this is the
responsibility of AG-controller vs
underlying<br>
services?<br>
<br>
How should the controller expose
resources to clients, how should the<br>
controller send data to its underlying
services, how much data should<br>
the controller be responsible itself
for?<br>
<br>
Should it be easy for an Operation
Transform system to integrate with<br>
AeroGear-controller?<br>
Should it be easy to write a
Controller based project which polls a<br>
third party source?<br>
How would the server handle passing
credentials to the third party source?<br>
<br>
Appendix Use Cases:<br>
<br>
Here are a few contrived use cases
that we may want to keep in mind.<br>
<br>
1. Legacy Bug Trackers From Hell<br>
a. It is a webapp written in COBOL, no
one will ever EVER update or<br>
change the code<br>
b. It has TONS of legacy but important
data<br>
c. It has TONS of users<br>
d. It only has a few transactions per
day, all creating and updating bug<br>
reports<br>
e. Multiple users can edit the same
report<br>
<br>
2. Slacker Gallery<br>
a. Each User has a multiple galleries,
each gallery has multiple photos<br>
b. A Gallery has only one user, but
the user may be on multiple devices<br>
c. Galleries may be renamed, created,
and deleted<br>
d. Photos may only be created or
deleted. Photos also have meta data<br>
which may be updated, but its creation
and deletion is tied to the Photo<br>
object.<br>
<br>
3. Dropbox clone<br>
a. A folder of files may be shared
among users<br>
b. There is a size limit to files and
how much storage may be used per<br>
folder<br>
c. Files are not updated. If there is
a new file, there is an atomic<br>
delete and create operation<br>
<br>
4. Email client<br>
a. This is an AG-controller which
accesses a mail account.<br>
b. There are mobile offline and sync
enabled clients which connect to<br>
this controller.<br>
<br>
5. Google Docs clone<br>
a. Operational Transform out the
wazzoo<br>
b. What would the server need?<br>
c. What would the client need?<br>
<br>
Appendix Reference (Open Source)
Products:<br>
<br>
Wave-in-a-box<br>
CouchDB<br>
Google Drive RealtimeAPI<br>
</div>
</div>
share.js<br>
etherpad<br>
<div><br>
Can you guys think of more
projects/examples to look at for
inspiration?<br>
</div>
</blockquote>
<div><br>
</div>
<div>We could take a look at the Grails
html5-scaffolding plugin which cover some
of this use cases <a
moz-do-not-send="true"
href="https://github.com/3musket33rs/html5-mobile-scaffolding"
target="_blank">https://github.com/3musket33rs/html5-mobile-scaffolding</a> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div> <br>
</div>
<div>
<div>_______________________________________________<br>
aerogear-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:aerogear-dev@lists.jboss.org"
target="_blank">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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<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>
</blockquote>
<br>
</div>
</div>
</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>