CloudServices/Notifications/Meetings/2011-01-18: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 40: Line 40:
=== DELETE Requests ===
=== DELETE Requests ===
*Revoking app privileges
*Revoking app privileges
**Data sent: JSON ={ "action"="REVOKE", "id"="DEFAULT", "tokens" : [token1, token2, token3] }
**Request URL: .../revoke/id/?tokens=token1,token2
**The question is whether or not we should send delete requests in batches or per app basis.  
**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.
**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.
**Solution: After a batch delete, send back a JSON containing an updated list of currently accepted apps.
**Solution: After a batch delete, send back a JSON containing an updated list of currently accepted apps.
*Alternativ #2:
**Data sent: JSON = {"action"="REVOKE", "id"="DEFAULT", "token":"token1"}
**An error response will be sent back if the app has failed to delete.


=== POST Requests ===
=== POST Requests ===

Revision as of 19:33, 20 January 2011

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.

Standards Agreed On:

Decided to send parameters using JSON.


GET Requests

  • Apps Registered
    • Check if app is registered
      • Request URL: .../is_registered/user_id/?app_host=mail.google.com&app_name=GMail
      • returns boolean {1/0}
  • Get the batch of all registered apps
      • Request URL: .../get_apps/user_id/
    • Data send: JSON = { "action"="get_apps", "id"="DEFAULT" }
    • returns JSON=[{"app_name":"...", "app_host":"...", "reg_date":"...", "token":"..."}, {...}, {...}]

DELETE Requests

  • Revoking app privileges
    • Request URL: .../revoke/id/?tokens=token1,token2
    • 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.
    • Solution: After a batch delete, send back a JSON containing an updated list of currently accepted apps.

POST Requests

  • Registering app
    • Data sent: JSON={"action"="REGISTER", "id"="DEFAULT", "app_name": "..", "app_host":"...", "token":"..."}

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 (anonymous) 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)