One thing that this brings up that I didn't see in the AGSYNC Jira (unless

clients.

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. 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? Happy Monday y'all, -- 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

On Feb 8, 2015, at 11:29 PM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: >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. You are right there is no JIRAs for this and it would be great if you could create one (We should have one for iOS as well). Could this be a targeted for an alpha.2 release?

On 9 February 2015 at 05:14, Summers Pittman <supittma(a)redhat.com <mailto: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. 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? Happy Monday y'all, -- Summers Pittman >>Phone:404 941 4698 <tel:404%20941%204698> >>Java is my crack. _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/aerogear-dev <https://lists.jboss.org/mailman/listinfo/aerogear-dev> _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Feb 9, 2015 at 5:14 AM, Summers Pittman <supittma(a)redhat.com <mailto: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(a)lists.jboss.org <mailto: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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

>Phone:404 941 4698 >Java is my crack.