On Mon, Feb 9, 2015 at 5:14 AM, Summers Pittman <supittma@redhat.com> wrote:

First the good news, I've refactored a lot of the xmpp-client code so
now the sync client is correctly handled by an Android service. This
gets around issues we were having earlier where the in-memory client
would get GCed while the doc was in the background as well as some
issues with loading documents when messages came in for the not
currently being edited doc.

Now the bad news, the past two weeks we've been focusing on using
Google's two way messaging for being the backbone of sync on Android for
alpha.1.  One of the issues we knew about was the 4k message size limit
in GCM and that after a POC phase we were going to have to address it.
On Friday I noticed that the server was choking on messages much smaller
than 4K.  Turns out that 4K includes all of the metadata around the
message in addition to the payload.  I do not think the GCM bridge is a
good tranport for alpha.1 and (if everyone agrees) will be focusing on
the WebSocket based client.

+9001 on a solid WebSocket client library for Android.

Especially for privacy our SYNC module should not rely on a 3rd party provider, like GCM, to sync the user's data (either entire documents or even patches).

For the integration of GCM/XMPP, IMO the best usage here is to just signal (or notify) the mobile app (e.g. while running in the background without a persistent connection to the Sync-Server) there is "new data" is available. The app could than (while still in the background) perform a connection to the users' Sync-Server and apply the data (e.g. patch), that was delivered directly from the users' Sync-Server instance. This way the users content is not exchanged over a 3rd party provider, like Google
 

One thing that this brings up that I didn't see in the AGSYNC Jira
(unless I'm blind) was how to manage the socket-connectivity interaction
on the clients.  Basically a protocol / pattern for how we manage the
socket connections when the device gains and loses internet access or
switches networks.  (For instance we should probably disconnect and
reconnect when the device leaves a cellular network and joins a Wifi
network)This is separate from collision handling/detection which does
have a Jira.  If there isn't one (a connection handling Jira) should I
make one?

Sounds like a good idea, to have that for the next iteration of our SYNC effort
 

Happy Monday y'all,

--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.

_______________________________________________
aerogear-dev mailing list
aerogear-dev@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