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