[whatwg] Inter-window communication beyond window.postMessage()

[Ian Hickson]

On Mon, 14 Sep 2009, Jeremy Orlow wrote:
> On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 14 Sep 2009, Sidney San Martín wrote:
> > >
> > > The cross-document messaging API solves a lot of problems and is 
> > > overall an Awesome Thing, but requiring a reference to the target 
> > > window is hugely limiting. When a a window wants to talk to another 
> > > window and didn't create it, there are basically three options:
> > >
> > > 1. window.open with a window name argument, which is a hack because 
> > > the target window has to reload.
> > > 2. Comet, which is a horrible hack because a trip to the server is
> > > required.
> > > 3. LocalStorage and storage events, which wasn't designed for 
> > > anything remotely like this.
> >
> > 4. Open a SharedWorker and send a MessagePort to the other window.
> >
> >
> > > Unless there's a reason to prevent free communication between 
> > > windows, there must be a better solution. I can think of a couple of 
> > > possibilities. The most obvious one would be an API similar to 
> > > postMessage that allows broadcasting of messages to all windows, 
> > > windows by name, and windows by domain. Another one (which I haven't 
> > > developed very far) would be to stick with window.postMessage but 
> > > provide an API to ask for windows. So, I could say, "Can I please 
> > > have a reference to the window named 'x'", or, "...to windows at 
> > > 'example.com'", or, "...to any window who'll give me one". Each 
> > > window would obviously have to opt into this.
> > >
> > > What do you all think?
> >
> > How do you know there's a Window to get a hold of if you don't have a 
> > hold of it already?
> >
> > The main reason for Window.postMessage() is communication with iframes 
> > (gadgets), not with other top-level browsing contexts. What's the use 
> > case for the latter?
> 
> I assume the use case for this is similar with the use case for storage 
> events which essentially is a broadcast mechanism that's specific to 
> just DOM storage.  So if, for example, you wanted to tell your other 
> windows "hey!  I changed the cookie" then you could do it with a 
> message.  This seems much better than, for example polling.
> 
> This could also be useful if you wanted to say "hey, I just navigated to 
> gmail.com.  Do any of you already have the inbox and chat contacts 
> loaded up?".  I suppose there's not much advantage to doing it like this 
> over shared workers since either way you're passing messages, but I also 
> don't see any major downsides to allowing broadcasts.

Yeah, a broadcast mechanism could make sense. Shared workers are probably 
a reasonable interim measure though, to help us gauge how much this is 
really needed.

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