[aerogear-dev] Sync Notes / Early issues

[Randall Hauch]

>From this and previous threads, it sounds like you’re targeting how multiple users could collaboratively edit the same document. Essentially, this is like Google Docs, though perhaps a bit lighter weight. Am I misunderstanding the scenario?

For example, would this kind of data sync be useful when there are millions of shared documents/entities? For example, a Yelp-like app would probably want to have an entity/document for each restaurant or business, where that document contained an aggregation of information about that business. In my mind, these kinds of documents are more akin to JPA entities — or rather akin to aggregates of related JPA entity objects.

Best regards,

Randall


> On Jan 26, 2015, at 9:38 AM, Summers Pittman <supittma at redhat.com> wrote:
> 
> 
> 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
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev