<div dir="ltr">><span style="font-family:arial,sans-serif;font-size:13px">what java client was used?</span><div><span style="font-family:arial,sans-serif;font-size:13px">There is an Java client for sync[1] which was used for the Android demo[2]</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">[1] </span><font face="arial, sans-serif"><a href="https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/diffsync/client-netty">https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/diffsync/client-netty</a></font></div><div><font face="arial, sans-serif">[2] <a href="https://github.com/danbev/android-diffsync-demo">https://github.com/danbev/android-diffsync-demo</a></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">></font><span style="font-family:arial,sans-serif;font-size:13px">on our sync-server, can't have have different "endpoints" (e.g. xmpp, websocket), </span><span style="font-family:arial,sans-serif;font-size:13px">that all connect to its heart, the </span><span style="font-family:arial,sans-serif;font-size:13px">Netty-based DiffSync engine?</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">This is what I had in mind when a wrote my comment about making the XMPP into a handler. It would not have to be tied to Netty, but we could use the XMPP server from within Netty and make sure that it get separate threading etc. </span></div><div><font face="arial, sans-serif"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 October 2014 09:46, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Oct 14, 2014 at 12:12 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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. </blockquote><div><br></div></span><div>what java client was used?</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> This seems to work "OK" but there is a lot of work<br>
getting websockets working right on Android. </blockquote><div><br></div></span><div>+1 </div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> 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></blockquote><div><br></div></span><div>on our sync-server, can't have have different "endpoints" (e.g. xmpp, websocket),</div><div>that all connect to its heart, the <span style="font-family:arial,sans-serif;font-size:13px">Netty-based DiffSync engine?</span></div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></blockquote><div><br></div></span><div>not sure I follow here</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></blockquote><div><br></div></span><div>looking forward to that. </div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
--<br>
Summers Pittman<br>
>>Phone:<a href="tel:404%20941%204698" value="+14049414698" target="_blank">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. </blockquote><div><br></div></span><div>any link to share?</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> 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></blockquote><div><br></div></span><div>instead of having our Android lib do a WS connection (including all the required work for maintaining etc), we could leverage the XMPP from GCM.</div><div>That's the prefered route you are suggesting, right ? </div><div><br></div><div><br></div><div>ANDROID <----> GCM <------> Sync-Server</div><div><br></div><div><br></div><div>This would allow us, to do more than we do atm on "pure" push notifications, via GCM. In this scenario we can do a two way communication:<br></div><div>Android client can send data to Sync-Server (via GCM), and receive "diff" from the server, via GCM.</div><div><br></div><div><br></div><div>-Matthias</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">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></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</font></span></div></div>
<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>