On 01/27/2015 01:32 PM, Matthias Wessendorf wrote:


On Mon, Jan 26, 2015 at 4:38 PM, Summers Pittman <supittma@redhat.com> wrote:

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

I'll figure this out with danbev.  He mentioned better integration for J2EE flavored things is a thing to investigate.  It may be that the sync-server is better served as a database styled thing and the app server is responsible for role based data security.

 
   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 ?

 * https://issues.jboss.org/browse/AGSYNC-28

I schedule it for beta.1.  Really this should be something that should be put together at the same time as persistent data.

 
   The in memory data store is problematic because clients and servers
must be stopped and started atomically

Dan created this for one of the later (alpha) releases:
https://issues.jboss.org/browse/AGSYNC-23
 
   We might want to show off syncing different types of documents (i.e.
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 it
"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)

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

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)
I talked to lolquist about it yesterday.  The final evolution of this idea is the only thing in the REST server is a secured endpoint which points you to a document on the sync server.  This means all of your information will be hosted directly from the sync server.
 

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

Already on it.  I have a few JIRAs and have brainstormed a set of fixes with passos.  Stay tuned.

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

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 slightly later
Sounds like we agree :)
 

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