One thing to have in mind here is privacy. If we sent the entire document (or just diff/patches) over a 3rd party provider like GCM, there are legal issues in a lot of (European) countries, where this is strictly verboten.

In the meeting (Feb 2nd, 2014) we identified a proper/robust WebSocket client lib for Android is a good way to "work around" the 4k data limit. Besides this technical reason and especially for privacy concerns, it is worth it to investigate on such a robust and stable WebSocket client lib for Android!

Using the WebSocket client for the data delivery, we no longer need to deliver the users data (actual document or just a patch) via a 3rd party provider, like Google. Instead the data/diff could be sent directly from the users' Sync-Server to the device and keeping the 3rd party provider out of the game).

Still I like the way to actually do a integration of GCM/XMPP, but 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.