<div dir="ltr">This sounds really nice! Looking forward to seeing it in actions. <div><br></div><div>><span style="font-family:arial,sans-serif;font-size:13px">Second, the sync server isn't multitenant. This means that until we </span><span style="font-family:arial,sans-serif;font-size:13px">figure out how to merge, things listening to WebSockets don't hear </span><span style="font-family:arial,sans-serif;font-size:13px">things listening to XMPP or see updates from one to the other.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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. <br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 October 2014 00:12, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TL;DR; Watch this repo over the next few days :<br>
<br>
<a href="https://github.com/secondsun/aerogear-sync-server/tree/xmpp-diff-sync" target="_blank">https://github.com/secondsun/aerogear-sync-server/tree/xmpp-diff-sync</a><br>
<br>
Currently I am researching integrating the sync client technology that<br>
DanBev, LolQuist et al have been working on into Android all proper<br>
like. Danbev wrote a POC demo a while ago* which uses the Java<br>
websocket client. This seems to work "OK" but there is a lot of work<br>
getting websockets working right on Android. However, Google has a two<br>
way messaging protocol built into Google Play Services on top of GCM.<br>
This is the technology I am trying to introduce to the sync systems in<br>
this branch.<br>
<br>
This branch includes a fork of the server library and a fork of the<br>
client library which interact with GCM on the client and XMPP on the<br>
server side. Right now it compiles and not much else. However, because<br>
the server is decoupled from the connection handling, adding in the<br>
correct hooks has been rather simple. There are going to be some issues<br>
to hammer out once this gets past "compiling" and makes it into "demoable".<br>
<br>
First, the server does not receive implicit connect/disconnect messages<br>
from Google per device. Google does send Ack/Nack messages however so<br>
with some bookkeeping connections/shadows/etc can be properly<br>
maintained. There is a similar mechanism on the client side; however,<br>
we may need to expand the sync protocol to include some kind of heartbeat.<br>
<br>
Second, the sync server isn't multitenant. This means that until we<br>
figure out how to merge, things listening to WebSockets don't hear<br>
things listening to XMPP or see updates from one to the other.<br>
<br>
Finally, Google Play Services is not FOSS by any stretch of the<br>
imagination. However, having a single connection managed by the OS is<br>
great for usability, speed of development, battery life, etc so I feel<br>
like this is more getting mileage out of the chunk of my soul I tossed<br>
in the black Googley shredder for UPS and less of a deal breaker.<br>
<br>
As I've said right now, today, this code is work in progress. Soon it<br>
will be proof of concept and we can discuss how to work around these<br>
issues and merge the ideas back into mainline.<br>
<br>
<br>
--<br>
Summers Pittman<br>
>>Phone:<a href="tel:404%20941%204698" value="+14049414698">404 941 4698</a><br>
>>Java is my crack.<br>
<br>
PS: WebSocket's biggest problems are maintaining connections and<br>
performing message redelivery in a sporatic connection scenario. This is<br>
one of those things which is a lot of work to get right both on our end<br>
as service providers and on the developer's end as consumers.<br>
Additionally, Android L is going to include a lot more end user<br>
configurability which will affect when/how messages are delivered. To<br>
do WebSockets right we will have to respect those settings as well. It<br>
is my assumption (we all know what that means) that Google Play Services<br>
will correctly enforce data/power settings out of the box as well as<br>
correctly maintain messaging connections and delivery.<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote></div><br></div>