[aerogear-dev] Sync Notes / Early issues

Matthias Wessendorf matzew at apache.org
Tue Jan 27 13:39:51 EST 2015


On Mon, Jan 26, 2015 at 6:00 PM, Randall Hauch <rhauch at redhat.com> wrote:

> 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
>

thanks for sharing. I create a ticket to evaluate this for a later (alpha)
release:
https://issues.jboss.org/browse/AGSYNC-27

-Matthias


>
>
> On Jan 26, 2015, at 10:31 AM, Summers Pittman <supittma at 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 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
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Summers Pittman
>
> Phone:404 941 4698
> Java is my crack.
>
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150127/cbfa553f/attachment.html 


More information about the aerogear-dev mailing list