CloudServices/Notifications/Meetings/2011-01-18
From MozillaWiki
< CloudServices | Notifications | Meetings
The meeting went along with the following presentation: File:FirstMeetingPrez.odp
Contents
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
- Request URL: .../apps/?app_host=mail.google.com&app_name=GMail
- Check if user is registered
- Request URL: .../user/userid
- Returns 200 is user exists, or 404 if not found
- Request URL: .../user/userid
- Get the batch of all registered apps (Requires Authentication)
- Request URL: .../apps
- Returns JSON: [{"app_name":"...", "app_host":"...", "reg_date":"...", "token":"..."}, {...}, {...}]
- Request URL: .../apps
- Get Notifications (Requires Authentication)
- Request URL: .../notifications
- Returns JSON: [{notif_1}, {notif_2}, ..., {notif_n}]
- Request URL: .../notifications
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.
- Request URL: .../apps/?tokens=token1,token2,...
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>×tamp=<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:
- Alex can receive notifications from Gmail on his browser
- Alex "lends" his computer to Shane to check Shane's email; Shane logs in
- Gmail discovers that it can send notifications to Alex's browser about Shane's email and asks for this.
- 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)