5:12 p.m.
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.
12:48 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:23 a.m.
interesting work Summers +1 to utilise platform native features
thanks for sharing
On Oct 14, 2014, at 1:12 AM, Summers Pittman <supittma(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:46 a.m.
On Tue, Oct 14, 2014 at 12:12 AM, Summers Pittman <supittma(a)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(a)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
2:55 a.m.
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-synchron...
[2] https://github.com/danbev/android-diffsync-demo
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. 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.
On 14 October 2014 09:46, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Oct 14, 2014 at 12:12 AM, Summers Pittman <supittma(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
3 a.m.
On Tue, Oct 14, 2014 at 9:55 AM, Daniel Bevenius <daniel.bevenius(a)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-synchron...
[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(a)apache.org> wrote:
>
>
> On Tue, Oct 14, 2014 at 12:12 AM, Summers Pittman <supittma(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
8:37 a.m.
I'll skip the questions DanBev Answered.
On 10/14/2014 03:46 AM, Matthias Wessendorf wrote:
On Tue, Oct 14, 2014 at 12:12 AM, Summers Pittman <supittma(a)redhat.com
<mailto:supittma@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
Google Play Services is proprietary software. I would
prefer to keep as
much stuff open source as possible. Since we have already agreed that
leaning on GPS is OK, I don't feel as bad about using it again.
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?
http://www.androidcentral.com/android-l-preview-battery-and-power-management
Specifically I had the Job Scheduler APIs in mind.
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 ?
Yes. XMPP is only
exposed on the server side. On the client side it
looks like Push notifications and calling a send method on the gcm client.
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.
Yes.
-Matthias
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>Phone:404 941 4698
>Java is my crack.
2:47 p.m.
On Tue, Oct 14, 2014 at 3:37 PM, Summers Pittman <supittma(a)redhat.com>
wrote:
I'll skip the questions DanBev Answered.
On 10/14/2014 03:46 AM, Matthias Wessendorf wrote:
On Tue, Oct 14, 2014 at 12:12 AM, Summers Pittman <supittma(a)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
Google Play Services is proprietary software. I would prefer to keep as
much stuff open source as possible.
ah, ok
Since we have already agreed that leaning on GPS is OK, I don't feel as bad
about using it again.
yeah, I agree it's not a bad thing to leverage that
>
> 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?
http://www.androidcentral.com/android-l-preview-battery-and-power-management
Specifically I had the Job Scheduler APIs in mind.
> 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 ?
Yes. XMPP is only exposed on the server side. On the client side it
looks like Push notifications and calling a send method on the gcm client.
sounds good.
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.
Yes.
sounds good!
-Matthias
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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
4119
days inactive
4120
days old
7 comments
4 participants
participants (4)
-
Christos Vasilakis -
Daniel Bevenius -
Matthias Wessendorf -
Summers Pittman