[whatwg] Installed Apps

[John Gregg]

Michael Kozakewich wrote:

> Are notifications really a renderer problem, as opposed to a browser-UI
> problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit')
> Also, I don't know of any notifications (Outlook, Messenger, AVG,
> TweetDeck, etc.) that require permissions, so I'd argue that requiring
> permissions for notification would be arguably confusing. It doesn't
> interrupt flow like alert() does.
>

It's not a renderer 'problem'; the code that would go in WebKit is just to
define the API and some basic logic about events flowing back and forth.
More work is certainly necessary beyond that (code which I am also writing
for Chromium).  The idea is that there be a standard notification API which
apps can write to and expect the intuitive thing to happen according to the
user agent & platform: on Mac these may go to Growl, on Linux to libnotify,
on Windows to toasts on the screen, on Mobile to something specific for the
device, etc.

I think there's a big difference in expectations for an installed native app
like those in your list versus a web page.  The user grants broad permission
when they install an app like that, but when they visit a web page the
expectation is very different. The fact that it's not modal like an alert
could even make it more necessary to secure: do you want an evil site to
spam your desktop with an unbounded # of toasts?  Again, I'm talking about a
notifications API which is independent of the "installed web app" idea also
being discussed in this thread.  It certainly might make sense that if there
is a way to install a web app in some form with a permissions step,
notifications could piggyback on that to avoid confusing prompts.


> Just in case I need to be set straight, here, I've got a couple questions:
> If vendors implemented this, they would have to work on their browsers,
> right? Is it easier for them to work on the rendering engine or on the
> application, or is there no difference? Do they prefer to add functionality
> to their rendering engine or to their application, or do they not care? (For
> these, I'm working from the assumption that it doesn't noticeably affect the
> UI, such as a new button or bar would.)
> And last: do they try not to touch the browsers, or do they prefer
> to delegate upgrades based on where they would be most suitable?
>

I'm not sure I follow the question, but I think it depends on the
architecture of the particular browser. Based on what I've proposed, a
browser maker would need to build all the pieces necessary to go from script
executing "notification.show()" to getting something on the screen.

I think answering those questions would help me the most, because at this
> point I don't know why they'd alter the renderer or JS engine to handle
> popup JavaScript instead of altering the browser to support what seems like
> a simple UI addition of pop-ups, but I do feel as though they wouldn't like
> to change the browser process.
> (As a final point, it's been mentioned that such a feature would become
> very popular, so many sites would implement it. It begs the question of
> which option is best for handling the volume of notifications and
> potentially abused notifications.)
>

Handling the volume falls on the browser or on the presenter of
notifications that the browser may might choose to delegate to (like
Growl).  I would think queuing based on available space is a reasonable
start.  Handling potential abuse is exactly why a permissions model is part
of the proposal.

 -John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090810/3125f7e1/attachment-0002.htm>