CloudServices/Notifications/Meetings/2011-01-18

From MozillaWiki
Jump to: navigation, search

The meeting went along with the following presentation: File:FirstMeetingPrez.odp

First Iteration Meeting

Goals for next week:

  • Demo - Three computers: Two clients, one web app.
    • Allow notifications from a web app using extension-created dialog
    • Notifications should appear immediately on both clients once web app pushes notification
    • Disable (revoke) notifications for particular app

Todos:

  • General
    • Set up user repositories
    • Use a richer JSON format / notifications ("type": "…", "id": "(app-generated ID)", "token": "…", "timestamp": "…", "payload": "…"})
  • Server-side:
    • Change how server handles multiple connections
    • Get grant and revoke API for "mailbox tokens" working
  • Client-side:
    • User is asked to receive notifications. The domain name of the site is displayed.
    • Browser makes token and hands it out to the user through callback.
    • Browser will also register the user, the app and the token with the server
    • Every Notification will display the domain name of where it's coming from
    • XUL code allowing for a preference window displaying all accepted domain names. User can delete notifications from there. (server will reflect this)
    • long polling approach revisited.

RESTful API

GET Requests

  • Check if app is registered
    • Request URL: .../apps/?app_host=mail.google.com&app_name=GMail
      • Returns 200 if app exists, or 404 if not found
  • Check if user is registered
    • Request URL: .../user/userid
      • Returns 200 is user exists, or 404 if not found
  • Get the batch of all registered apps (Requires Authentication)
    • Request URL: .../apps
      • Returns JSON: [{"app_name":"...", "app_host":"...", "reg_date":"...", "token":"..."}, {...}, {...}]
  • Get Notifications (Requires Authentication)
    • Request URL: .../notifications
      • Returns JSON: [{notif_1}, {notif_2}, ..., {notif_n}]

DELETE Requests

  • Revoking app privileges (Requires Authentication)
    • Request URL: .../apps/?tokens=token1,token2,...
      • Returns 200 if all tokens were removed successfully; 403 otherwise
    • The question is whether or not we should send delete requests in batches or per app basis.
    • Reason: out of sync. If two preference dialogs are opened in two different browsers synced on the same account name, browser 1 revokes privileges for app1 and app2, and browser 2 revokes privileges for app1 and app3, app1 will already have been deleted.

POST Requests

  • Registering app token (Requires Authentication)
    • Request URL: .../apps
    • Message Body: app_name=<name>&app_host=<host>&token=<token>
      • Returns 201 if app token was registered successfully
  • Send notification
    • Request URL: .../notifications
    • Message Body: token=<token>&type=<type>&timestamp=<unixtime>&payload=<msg>
      • Returns 201 if notification created successfully
  • User Registration
    • Request URL: .../user
    • Message Body: username=<username>&password=<password>
      • Returns 201 if user was registered successfully

Future issue:

  1. Alex can receive notifications from Gmail on his browser
  2. Alex "lends" his computer to Shane to check Shane's email; Shane logs in
  3. Gmail discovers that it can send notifications to Alex's browser about Shane's email and asks for this.
  4. How does Gmail know who is it sending notifications to?

Potential Answer: Have a promiscuous mode (or anonymous mode?) that Alex can activate before lending his machine? (disables all notifications)

Discussion Points:

  • Q: How do we handle spoofing?
    • A: We don't. Display a dialog with domain included "GMail (mail.google.com) wants to send you notifications. Allow?" User responsible for this.
  • Q: Should we use a doorbell mechanism?
    • A: No. Involves a lot of overhead; FeedURL (persistence especially) would be difficult to implement by clients. "Joe's Bakery just wants to push a button and send notifications, not build its own feed mechanism"

Upcoming meetings to be scheduled with:

  • UX
  • bsmith (crypto)
  • rnewman (Queuing systems)