← Back to team overview

ubuntu-push-devs team mailing list archive

Re: kicking off: the plan so far

 

On Tue, Aug 6, 2013 at 1:44 PM, John Lenton <john.lenton@xxxxxxxxxxxxx>wrote:

> 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?
>
> --
> Mailing list: https://launchpad.net/~ubuntu-push-devs
> Post to     : ubuntu-push-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-push-devs
> More help   : https://help.launchpad.net/ListHelp
>

References