[whatwg] Notifications: in workers

[Ian Hickson]

On Wed, 3 Apr 2013, Simon Pieters wrote:
> On Sun, 31 Mar 2013 16:40:16 +0200, Anne van Kesteren <annevk at annevk.nl> 
> wrote:
> > 
> > There is some interest in exposing Notification objects in a worker so 
> > creating one does not require a postMessage() roundtrip.
> > 
> > This seems problematic for shared workers as it is not clear which 
> > window the notification would be for. For normal workers this seems 
> > like less of a concern.
> > 
> > If we go with the idea of exposing a URL on Notification objects and 
> > allow that to be set we might be able to address the shared worker 
> > issue, but it is not entirely clear to me which semantics are 
> > desirable there.
> 
> My knee-jerk reaction is to tie it to MessagePorts, so that if you make 
> a notification on a port, the window that owns the entangled port 
> displays the notification. If there isn't an entangled port or if it's 
> not in a window, I guess it could silently fail.
> 
> The above would enable making notifications from one window on behalf of 
> another window, if there's a message channel between the two.

You could do this today anyway, manually, right? (That is, the page could 
provide an API that it vends as a port that just proxies the notification 
API.) How necessary is it to do this natively?

Note that one problem with putting notifications in workers is that it 
means we can't have rich notifications with exposed DOMs until workers 
have DOMs. Not sure if that's on the cards, but notification systems on 
other platforms are getting _quite_ rich indeed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'