[whatwg] Installed Apps

[Michael Kozakewich]

From: "Jonas Sicking" <jonas at 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.