On Mon, Jan 26, 2015 at 4:38 PM, Summers Pittman <supittma(a)redhat.com>
Summary (From my POV on Android):
Sync Server doesn't use any authentication or ownership tracking.
that's fine, for alpha.1. Can you create a ticket to track this on AGSYNC
for later alpha releases? Or do we have already such an issue
GCM-XMPP bridge needs a lot of love
We need to define a different connection lifecycle for GCM.
Similar to above, I think for initial alpha the current connection bridge
may be OK. We have JIRAs for that ?
The in memory data store is problematic because clients and
must be stopped and started atomically
Dan created this for one of the later (alpha) releases:
We might want to show off syncing different types of documents
a todo list in addition to Luke's hobbies)
Let's make sure the epics for the demos are covering that. Perhaps worth to
open a new thread,
if we really need a new demo or so for the alpha.1
Fixing the GCM bridge is probably a couple weeks of work to get
"solid". That will be a good alpha.1/preview to show off.
ok, but I think if the only the current bridge makes it, it would not be
the end of the world.
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.
+1 like the idea
Here's a flow
chart for the visual thinkers out there (with real screen caps from the
real working app)
nice diagram - looks like a solid flow
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.
your restful server would be the backend, that should/clould be 'plugged'
into the sync? (in a later release)
The client uses the GCM XMPP¹ bridge I wrote while drunk on the side of
a mountain and it shows.
:-) Ok, perhaps we should get it improved before we ship alpha.1
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.
sounds like a bug
GCM-XMPP doesn't supply connection/disconnection information
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.
the messages that are arrving via GCM could be used to query for the
version from the sync server. Eg. via a REST API?
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.
I think ideally the release would be ready around 20th of Feb, perhaps
>>Phone:404 941 4698
>>Java is my crack.
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