<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 class="h5"><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 style>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 class="h5">
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 style>Shouldn't we trigger a sync only when we go from an offline status to an online status ? And sync strategy should be configurable (both on client side and server side) </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 class="h5">
<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 style>Yes, we should promote push but have a fallback to a pull strategy </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 class="h5">
<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 style>I would add another option :</div><div style>E. The Strongest always win : i.e An admin user change will always be considered with a higher weight when merging a conflict. </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><div class="h5">
<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 style>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 style>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 class="h5">
<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 class="im"><br>
Can you guys think of more projects/examples to look at for inspiration?<br></div></blockquote><div><br></div><div style>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">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 class="im">
<br>
</div><div class=""><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div></div>