ubuntu-push-devs team mailing list archive

[Lucio Torre <lucio.torre@xxxxxxxxxxxxx>]

>
> Facebook --(pushing) JSON--> Push server --JSON--> Push daemon --JSON-->
> Facebook App
>
> However that's not something that I can will into existence on my own.
>

Yes, this is the use case we are designing for.


>  So, what I've gathered is that Friends, if it even continues to exist at
> all, is going to end up looking something like this:
>
> Facebook <--(polling) JSON--> Friends cloud server --(pushing) JSON-->
> Push server --JSON--> Push daemon --JSON--> Friends --DBus--> friends-app
>
> And, if that's the case, then my question becomes: if I have to implement
> my own server in the cloud somewhere, what benefit am I even getting from
> the push service? Why wouldn't I just do this directly:
>
> Facebook <--(polling) JSON--> Friends cloud server --(pushing) JSON-->
> Friends --DBus--> friends-app
>

The proposed solution just http posts somewhere when there is a
notification and the app will get it. If you want to build it yourself you
would still need to have the app always running (not possible due to the
lifecycle model) and have it connect to your server, where you hold one
open connection for each device waiting to be notified (in the general case
you cannot connect from the cloud to a device directly). Also, if the
device is not connected you need to store it so it can be delivered when it
connects. So there is an increased complexity even without considering the
lifecycle impossibility. (You are a system daemon, so you might get special
privileges regarding that, but again, that's not our primary use case)

The other critical reasons why you want to use the push service is because
persistent connections of this type need to be tuned to reduce battery and
network usage. And most of the gains come from packing messages from all
apps and sending them in one go instead of sending them as they arrive. For
that we need a system that sees all notifications.

If facebook, twitter and g+ notify every 30 minutes each, you might be
waking up the device and using network every ten minutes instead of the
optimum of once every 30 minutes. And doing this properly is a carrier
requirement, they will not allow devices on their network that are
requesting channels all the time, even if they just want to send one byte.
60 bytes on the hour is a lot better that 1 byte per second.

So there is some engineering required that gains from centralizing all of
this traffic and tuning it.

I see how this solution is a lot more expensive to you than the current
"have the device do polling" solution, but i don't think it's a problem
with the solution we propose, but a problem with needing to poll, which we
cannot allow on the device.

Lucio.