ubuntu-push-devs team mailing list archive

[John Lenton <john.lenton@xxxxxxxxxxxxx>]

Hello all!

So, push notifications.

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

After several ongoing discussions with different people,

Phase -1: exploratory work

I'm currently throwing together disposable code to get all the bits
up, conceptually at least: a server-side daemon, a client-side daemon,
an client app, and a app server. All python, exploratory code. This
will let us quickly (before end-of-week, if all goes well) test the
ideas behind v0 of the API with running code. It will also set the v0
API in stone once we've decided it's done.

I expect that setting-in-stone to happen by end of next week, which
would kick off the next phase.

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.

The server side will be in Go (probably), the client-side daemon in
C/C++, there'll be a QML component that app devs can use to get access
to the functionality (maybe but not necessarily covering the basic
"translate and show the message" use case already).

The expectation is that we will have very few apps actually using this
version of the API, because people will only start using the API once
v0 is out there, hence why waking the app every time isn't too much of
a concern.

In a perfect world, v0 would be ready the last days of September.
Committing to that at this stage would be overambitious, however.

Phase 1: version 1

Version 1 would add multiple message modes to the protocol, and a
smarter client-side server to handle some things without waking the
app.

Phase 1 should be ready in Q1 2014.

Phase 2: version 1.1

Version 1.1 would add a preferences app, and server-side smarts to
work with GSM or GSMA services where that makes sense and is
available.

Phase 2 should be ready before the heat death of the universe.


Questions? Comments? Obvious things I've forgotten or am overlooking?