- From: Michael Kozakewich <mkozakewich@icosidodecahedron.com>
- Date: Sat, 8 Aug 2009 00:00:30 -0500
From: "Jonas Sicking" <jonas@sicking.cc> Sent: Friday, August 07, 2009 5:07 PM > 2009/7/30 Ian Fette <ifette at google.com>: >>> That being said, I think there are valid use cases for out-of-band >>> notifications, for example for calendar events or "status update" type >>> applications such as Facebook or Twitter. >>> >>> I'd like to explore whether we can accommodate this notification use >>> case >>> without bringing the full power of the Web platform to bear, and thereby >>> opening up a lot of attack surface on the client. Here's one rough >>> sketch of >>> an idea: >>> >>> * Notification Feeds * >>> >>> Often, web applications would like to give users the option to subscribe >>> to notifications that occur at specific times or in response to >>> server-side >>> events, and for the user to get these UI notifications without a >>> prerequisite that the web app is open or that the browser is running. >>> There >>> may be a desire to do client-side computation as well, but often just >>> the >>> ability to give the user a notification solves the basic user >>> interaction >>> problem. >>> >>> One possible way to address this kind of use case is to let users >>> subscribe to a "feed" of notifications. This feed could use standard >>> syndication formats, such as RSS or Atom. But instead of being displayed >>> in >>> a traditional feed reader, it's displayed in the form of transient >>> notifications (along the lines of Growl on Mac OS X) which are posted >>> for >>> each new event. To allow some pre-scheduling of events, each item can >>> have a >>> date and won't be displayed until that date - this way a calendar can >>> give >>> you your feed of upcoming events and you can still get notifications >>> when >>> offline. In the case of something like email or Twitter, obviously >>> there's >>> no sensible way to get notifications when offline since they depend on >>> unpredeictable server-side activity. There could even be a client-side >>> API >>> that lets a Web app schedule items on a subscribed notification feed >>> from >>> script, to enable scheduling calendar events offline. Each notification >>> would have the option to unsubscribe from the notification feed, to >>> reduce >>> spam potential. >>> >>> Notice that this opens up a lot less attack surface. The user has to >>> actively opt in to subscribing to the notification feed, just as for an >>> RSS >>> feed. This makes it much less likely they end up with a subscription to >>> a >>> shady site. And the notifications are passive data items (probably no >>> script >>> should be allowed in a notification, if the format is HTML and not just >>> plain text), so they open up a lot less security risk. Obviously this is >>> less powerful than the ability to run arbitrary code in the background. >>> But >>> it could address a large chunk of the use cases with much less security >>> risk. >> >> It addresses some use cases (calendar, perhaps), but I would still like >> to >> be able to e.g. keep my email up to date. Do I need the "full power" / >> "fully general" solution? I don't know, perhaps the push mechanism can be >> structured in a way that it gets into my database or whatever storage >> mechanism I am using for offline data storage? For the purpose of notification, it seems we have the following solutions: -Push message -SMS -RSS/Atom feed -Polling (Probably through JavaScript) Which will manifest in the following types of program: -Hidden browser page, Standalone browser tab, Persistent worker, or the browser's main background process, as part of the browser -Extraneous app or device (SMS to phone, or small-footprint desktop feed-reader) Any others you can add to those lists? (You can read the rest, or visit the summary near the bottom.) To go through the methods: RSS/Atom is usable at this very moment, as is JavaScript polling and SMS. SMS can be expensive, but Twitter has proven how useful it can be. I'm not sure what applications support push messages. Deciding where the messages appear is the tricky part: A low-footprint, invisible feed-reader app can be run in the background and pop up messages when they're received. This will require users to install third-party tools, which could integrate themselves with the browsers to open links or manage 'feeds'. Phones could be used to handle SMS notifications or push messages. The browsers could check for updates in a tab, but there are a couple things that need to change before this becomes feasible: 1) Browsers need to be able to pop up a notification in the corner, possibly with a link that sets focus to the notifying tab, 2) Browsers need to get the notifying tab out of the way, either by shrinking it to a notification area or by running it as a background process (where it can be accessed from the browser through some sort of Application Manager), and 3) Hidden tabs need to continue to run when the browser is closed (i.e. the browser's main process continues to run) until the hidden page is exited. It sounds like the browser could have a small background process that manages notifications, and a webapp (such as Gmail) could register with the browser's notification process. That could be separate from the idea of tearing off the webapp tab and keeping it as its own process, even past the life of the rest of the browser. For this part, I urge you all to check out Chrome's "Create Application Shortcuts" feature, because it seems to fulfill this use-case. In addition to what Chrome does, I'd suggest the option to minimize to notification area, or hide in a list of torn-off apps in some kind of Application Manager. ----------------------------------- ----------------------------------- TO SUMMARIZE: -There are many other existing ways to notify -I'd suggest browsers have a Notification process with which open tabs register. -Registered open tabs could tell the browser to pop up a notification, perhaps with title text, body text, and image -Clicking the notification would set focus to the browser and to the notifying tab. To solve the lifetime issue: -Torn-off tabs run in separate processes -Processes may be re-skinned to appear as applications, but are really tabs. -Minimized/docked Processes taken off the taskbar/dock and into a notification area or Application Manager -If the rest of the browser is closed, the main process will stay on until the application tabs are closed -Browser's 'Application Manager' in notification area or taskbar/dock (and as a button in the main browser) holds all open application tabs Have I forgotten anything? Even without the application tabs, the notification process would be great to implement.
Received on Friday, 7 August 2009 22:00:30 UTC