[aerogear-dev] Sync on Android

[Daniel Bevenius]

This sounds really nice! Looking forward to seeing it in actions.

>Second, the sync server isn't multitenant.  This means that until we figure
out how to merge, things listening to WebSockets don't hear things
listening to XMPP or see updates from one to the other.
I was thinking that perhaps we can have the XMPP server part of the Netty
DiffSync server as well. It would be pretty much as it right now, but be a
Netty channel handler in the same pipeline. Let me know if this makes
sense. Let me know if what you think and if you like I'd be happy to take a
stab at this.



On 14 October 2014 00:12, Summers Pittman <supittma at redhat.com> wrote:

> TL;DR; Watch this repo over the next few days :
>
> https://github.com/secondsun/aerogear-sync-server/tree/xmpp-diff-sync
>
> Currently I am researching integrating the sync client technology that
> DanBev, LolQuist et al have been working on into Android all proper
> like.  Danbev wrote a POC demo a while ago* which uses the Java
> websocket client.  This seems to work "OK" but there is a lot of work
> getting websockets working right on Android.  However, Google has a two
> way messaging protocol built into Google Play Services on top of GCM.
> This is the technology I am trying to introduce to the sync systems in
> this branch.
>
> This branch includes a fork of the server library and a fork of the
> client library which interact with GCM on the client and XMPP on the
> server side.  Right now it compiles and not much else.  However, because
> the server is decoupled from the connection handling, adding in the
> correct hooks has been rather simple.  There are going to be some issues
> to hammer out once this gets past "compiling" and makes it into "demoable".
>
> First, the server does not receive implicit connect/disconnect messages
> from Google per device.  Google does send Ack/Nack messages however so
> with some bookkeeping connections/shadows/etc can be properly
> maintained.    There is a similar mechanism on the client side; however,
> we may need to expand the sync protocol to include some kind of heartbeat.
>
> Second, the sync server isn't multitenant.  This means that until we
> figure out how to merge, things listening to WebSockets don't hear
> things listening to XMPP or see updates from one to the other.
>
> Finally, Google Play Services is not FOSS by any stretch of the
> imagination.  However, having a single connection managed by the OS is
> great for usability, speed of development, battery life, etc so I feel
> like this is more getting mileage out of the chunk of my soul I tossed
> in the black Googley shredder for UPS and less of a deal breaker.
>
> As I've said right now, today, this code is work in progress.  Soon it
> will be proof of concept and we can discuss how to work around these
> issues and merge the ideas back into mainline.
>
>
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
>
> PS: WebSocket's biggest problems are maintaining connections and
> performing message redelivery in a sporatic connection scenario. This is
> one of those things which is a lot of work to get right both on our end
> as service providers and on the developer's end as consumers.
> Additionally, Android L is going to include a lot more end user
> configurability which will affect when/how messages are delivered.  To
> do WebSockets right we will have to respect those settings as well.  It
> is my assumption (we all know what that means) that Google Play Services
> will correctly enforce data/power settings out of the box as well as
> correctly maintain messaging connections and delivery.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141014/340bffc8/attachment-0001.html