[whatwg] Inter-window communication beyond window.postMessage()
ian at hixie.ch
Tue Sep 15 17:47:20 PDT 2009
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
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg