Re: [aerogear-dev] Sync Notes / Early issues

On 01/27/2015 01:32 PM, Matthias Wessendorf wrote: On Mon, Jan 26, 2015 at 4:38 PM, Summers Pittman <supittma(a)redhat.com&gt; 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_gcDE... 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(a)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 _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev