[aerogear-dev] Sync Notes / Early issues

[Summers Pittman]

Summary (From my POV on Android):

   Sync Server doesn't use any authentication or ownership tracking.
   GCM-XMPP bridge needs a lot of love
   We need to define a different connection lifecycle for GCM.
   The in memory data store is problematic because clients and servers 
must be stopped and started atomically
   We might want to show off syncing different types of documents (i.e. 
a todo list in addition to Luke's hobbies)
   Fixing the GCM bridge is probably a couple weeks of work to get it 
"solid".  That will be a good alpha.1/preview to show off.

So Last week I put together a demo to try and stretch the legs of the 
Android Sync Client APIs.

It crashes, a lot.  Which is a bit to be expected as the code hasn't 
really be used for, well, anything until now.  We will get to that though.

Here is the alpha.1 workflow. You log in and you see your docs.  You can 
edit your docs or you can create new ones.  In the future I would like 
to add sharing and collaboration but that's the future. Here's a flow 
chart for the visual thinkers out there (with real screen caps from the 
real working app)

  * 
https://docs.google.com/drawings/d/145XuutxR1yY0k81w2nIIy980itDIwxzH_gcDE3jLrvc/edit?usp=sharing

To make all of this work I use a RESTful server which tracks a user's 
username and the documents they "own".  The sync server just syncs and 
serves the document you ask for.  It has no authentication and any doc 
you ask for you get to be an editor on.

The client uses the GCM XMPP¹ bridge I wrote while drunk on the side of 
a mountain and it shows.  The biggest issue is that shadows for 
documents aren't getting created right sometimes because either 1) the 
client or server bounced and the data stores are no long synced or 2) 
the server thinks there are more clients than actually are connected.  
GCM-XMPP doesn't supply connection/disconnection information like 
WebSockets will.  Instead we just know that some messages we sent a 
while ago weren't delivered.  We need to figure out how to turn this 
into connection and disconnection information in a way that lets the 
shadows exist correctly.

Another issue that needs to be addressed is using something other than 
the Luke Skywalker hobbies document.  (Or maybe showing off multiple 
document types in the demo).  I'm up for suggestions.

Anyway, the principles (diff sync with a restful documentId broker for 
security) are sound.  I think we can buff out some implementation 
details and have a good alpha/preview/poc release in the few weeks -> 1 
month time frame for Android and the sync server.

-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.



Foot Notes:
1. The sync server has two client connection technologies : WebSockets 
and GCM-XMPP.  Android uses the GCM-XMPP because it takes all of the 
nasty connection handling code and gives let's Android deal with it.  
More info here : https://developer.android.com/google/gcm/ccs.html