[whatwg] Installed Apps

[Michael Kozakewich]

From: John Gregg 
Sent: Monday, August 10, 2009 2:34 PM

  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

For some reason, I seemed to forget that the call would be made through JavaScript in either case.

I only briefly touched on the idea of 3rd-party apps like feed-readers, because I'm really not enamored with the idea. My main thought was that the browser itself would have a notifications process that would be subscribed to, and then the tabs could post messages to it. The browser would police that. (It could automatically register the tab as the first post method was sent, and unregister when that tab was closed). I don't believe such a process would have inherent security concerns, if the process was thought out (all it needs is presentation/layout). In this way, you wouldn't need to install the app to use notifications. I just wonder about policing (give a little notification, like when pop-ups are blocked, with option allowing notifications for the whole site? +Whitelisting?) 

I admit I worded the browser/renderer questions horribly. I meant the difference of using JavaScript to pop up an HTML message, with a bit of help from the browser; as compared to posting to the browser with JavaScript and having the browser pop up a message with its own (themeable) UI, like what one might expect from an extension. Both need everything to work together, but they have different focuses.
I'd imagine (from other WHATWG discussion) the HTML version would have scripting, as if it were another page, and it would be designed with images and CSS. It could have links and such, too. Not secure.
I'd imagine the Browser version having a themeable-but-consistent notification UI that would simply serve to inform the user of (and, by default, onClick set focus to) a tab with new data.

Most of the last paragraph of my previous email can just be ignored. I think I had completely forgotten about the API, or how code ties into the structure of the browser.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090810/b9b3efc8/attachment.htm>