[aerogear-dev] Sync on Android

Tue Oct 14 04:00:25 EDT 2014

On Tue, Oct 14, 2014 at 9:55 AM, Daniel Bevenius <daniel.bevenius at gmail.com>
wrote:

> >what java client was used?
> There is an Java client for sync[1] which was used for the Android demo[2]
>
> [1]
> https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/diffsync/client-netty
> [2] https://github.com/danbev/android-diffsync-demo
>

thanks for sharing!

>
> >on our sync-server, can't have have different "endpoints" (e.g. xmpp,
> websocket), that all connect to its heart, the Netty-based DiffSync
> engine?
> This is what I had in mind when a wrote my comment about making the XMPP
> into a handler.
>

hehe

> 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.
>

sounds good!

>
>
> On 14 October 2014 09:46, Matthias Wessendorf <matzew at apache.org> wrote:
>
>>
>>
>> On Tue, Oct 14, 2014 at 12:12 AM, 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.
>>
>>
>> what java client was used?
>>
>>
>>
>>> This seems to work "OK" but there is a lot of work
>>> getting websockets working right on Android.
>>
>>
>> +1
>>
>>
>>> 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.
>>>
>>
>> on our sync-server, can't have have different "endpoints" (e.g. xmpp,
>> websocket),
>> that all connect to its heart, the Netty-based DiffSync engine?
>>
>>
>>
>>>
>>> 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.
>>>
>>
>> not sure I follow here
>>
>>
>>>
>>> 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.
>>>
>>
>> looking forward to that.
>>
>>
>>>
>>>
>>> --
>>> 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.
>>
>>
>> any link to share?
>>
>>
>>> 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.
>>>
>>
>> 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.
>> That's the prefered route you are suggesting, right ?
>>
>>
>> ANDROID   <----> GCM <------> Sync-Server
>>
>>
>> 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:
>> Android client can send data to Sync-Server (via GCM), and receive "diff"
>> from the server, via GCM.
>>
>>
>> -Matthias
>>
>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141014/6dc5387f/attachment.html 