ubuntu-push-devs team mailing list archive

[John Lenton <john.lenton@xxxxxxxxxxxxx>]

If you go and repull lp:~chipaca/+junk/shove and launch, in order,
`srv`, `cli` and `app`, you'll see app print out a registration id.
You can then use that as the first parameter to `msg`, and all the
little bits will do their dance. You can play with the options (at the
"shove" and the subcommand level) to break it or test it in different
ways. Keep in mind the server skips the whole "more than one user"
thing for now, so that will break in fun ways.

This is mostly done (more on what's missing in a minute). I'm fairly
happy with the public API it exposes:

1. the application developer gets a key/token it needs to keep on the
app server to authenticate with the notifications server.

2. on app setup, the app talks to the client-side daemon over dbus to
create a registration (specifically: it calls
com.ubuntu.PushNotification.create_registration(registration_name,
app) on com.ubuntu.PushNotifications/shove, if that makes sense (is
there a convention for specifying all the dbus bits in prose?)).

3. [NOT IMPLEMENTED] the client-side daemon needs to verify that the
create_registration call came from the app it's purported to be coming
from. Easiest way I can think of is to do a second call over dbus,
back to the app (rather like the other calls the client-side daemon
does to the app), with some kind of challenge/response.

4. the client-side daemon talks to the notifications server and gets
back a registration id. The way this is done is not part of the API.
It ties the registration to the user and device that requested it.

5. the client-side daemon talks to the app to deliver the registration
id. The reason (5) is not simply the return value to the call in (2)
is because (3) and (4) can take a long time. The method is
com.ubuntu.PushNotification.registration_created(name, id), on the
/shove path of the app's bus name.

6. the app gets the registration id to the app server somehow. Between
permissions and app lifecycle and all that, we might need to offer a
service to do this for the app. Not for v0, I think.

7. The app server does a rest call to the notifications server,
POSTing to /message, with the registration id and the message. Note
that v0 won't necessarily support it, but this supports multiple
registration ids for a single message.

8. notifications server delivers the message to the appropriate
user/device combo. How? not part of the API.

9. the client-side daemon calls
com.ubuntu.PushNotification.receive_message(registration_name,
message) on the /shove path of the app's bus name.

10. the app segfaults, or any other appropriate action.


So! Now.

Thoughts?

Better names for these API endpoints?

Cake?