ubuntu-push-devs team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Tue, 2013-08-06 at 12:44 +0100, John Lenton wrote: 

> We want to have a push notifications story that does a bunch of neat stuff:
> 
>  * very low power consumption on the client
>  * end-to-end encrypted
>  * smart (locale-aware) client-side message handling to avoid waking
> apps up for notifications that don't need it
>  * have a preferences app (possibly synced to the server) to select
> which apps get notified and how
>  * have multiple "modes" (at-most-once, at-least-once,
> once-and-only-once, only-on-tuesdays*, etc)
>  * use operator-provided backend services when available and useful



It seems that it'd be nice if we could use an already existing protocol
instead of inventing our own.  Rumor seems to have it (I haven't seen an
official source) that XMPP is the solution of choice here. (slide 4)

http://www.slideshare.net/processone/processone-push-platform-xmppbased-push-solutions-10203898

That would be nice for us as we could use Telepathy, a daemon that is
already running on the system, to dispatch the messages.  It also has a
"battle hardened" XMPP implementation that we ship.  Always good for
network stuff.  Also it might save us, at least for first versions, from
having to build our own server from scratch.  We can just write ticklers
instead of the router.


> Phase 0: version 0
> 
> Version zero of the API will only support a single message type
> (at-most-once), there'll be no preferences, and the app will be
> notified (i.e. woken or started up) for every message. It's the
> exploratory work, but done by actual engineers and with things like
> tests and QA.


We don't currently have a state for application started and not shown.
So this would result in the application probably being brought into the
foreground (not sure exactly yet), which would obviously be something we
couldn't ship to users.  Is that okay?  Or do we need to solve some of
the application management issues sooner than that?

Ted

Attachment: signature.asc
Description: This is a digitally signed message part