On a related note, I recently finished a prototype for a backend storage solution that stores JSON documents (entities) in collections and zones, and has a number of other features. There were several goals, including several that were just focused on backend technologies (e.g., fault tolerance, scalability, data safety, performance, what can be done without transactions, etc.). With limited time, I also wanted to focus on the more unknown and higher risk stuff, so I deferred several other far more straightforward things like wrapping with a server (e.g., Undertow, a LiveOak subsystem, etc.) and using AeroGear’s UPS. One thing I did look into is what kind of interchange might work best for mobile apps reading and updating data, and how mobile apps can synchronize their local state (e.g., data sync).

I’m not sure what (if anything) are the next steps for this, but all of it is at https://github.com/rhauch/debezium. I’d be interested in getting feedback on the concept, the approach, the documentation, etc., so if you’re interested in learning more perhaps the best place to start it at the wiki: https://github.com/rhauch/debezium/wiki


On Jan 26, 2015, at 10:31 AM, Summers Pittman <supittma@redhat.com> wrote:

On 01/26/2015 11:26 AM, Randall Hauch wrote:
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?
Document is a generic term.  It is a wrapper around a JSON serializable object.

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.
Yes ish.  Right now the sync server is very young, but we can model the data as a single document and have the apps display views into it and make edits appropriately.  The trick will be making sure that the serialization is always the same (IE two clients aren't constantly updating because they serialize data in different orders)

Best regards,

Randall


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

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


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