[aerogear-dev] Sync Notes / Early issues
Summers Pittman
supittma at redhat.com
Tue Jan 27 15:46:41 EST 2015
On 01/27/2015 03:40 PM, Matthias Wessendorf wrote:
>
>
> On Tue, Jan 27, 2015 at 8:43 PM, Summers Pittman <supittma at redhat.com
> <mailto:supittma at redhat.com>> wrote:
>
> On 01/27/2015 01:32 PM, Matthias Wessendorf wrote:
>>
>>
>> On Mon, Jan 26, 2015 at 4:38 PM, Summers Pittman
>> <supittma at redhat.com <mailto:supittma at 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.
>
>
> e.g. like JAX-RS extensions/adapters that can community with the
> "sync-server" resource?
Basically. Something something annotations and CDI
>
>
>
>> 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.
>
>
> ok
>
>
>>
>> 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.
>
>
> nice
>
>
>
>> 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 :)
>
>
> perfect :-)
>
>
>>
>> --
>> 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
>> <mailto: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
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto: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 <mailto: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
>
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150127/ecfa8788/attachment-0001.html
More information about the aerogear-dev
mailing list