Re: [whatwg] Inter-window communication beyond window.postMessage()
On Tue, 15 Sep 2009, Sidney San Martín wrote: > > > > On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson wrote: > > > > 4. Open a SharedWorker and send a MessagePort to the other window. > > I'm not too familiar with shared workers, but I read through the spec > and it looks like they suffer from the SOP (as Drew mentioned). > (LocalStorage also suffers from this, I shouldn't have included it in > the original post.) SOP? > > How do you know there's a Window to get a hold of if you don't have a > > hold of it already? > > You don't. What's common among the use cases for this kind of > inter-window communication is that you are trying to talk to windows > which may have been around longer than you or were created after you. If > the call fails or you get no response, handle it (tell the user, open > the window, or do nothing.). Seems like a shared worker is the best way to do that, since that way you don't have to worry about a master election each time one of the windows you're talking to closes. > > 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? > > On Mon, Sep 14, 2009 at 8:57 PM, Jeremy Orlow wrote: > > 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. > > The original case that made me start exploring these APIs was a "stuff > browser" that I'm working on (think address book). The browser stays > open (as a popup) and can be used alone, but other pages should be able > to ask it to navigate to a specific record. A shared worker would > actually work quite nicely in this situation, but wouldn't work at all > across-domains. That's an interesting use case. (You can work around the current limitation of shared workers being same-domain only by having an iframe to proxy the request to talk to the shared worker, and then getting it to post you back a pipe to the worker. Not hugely elegant, but it'll work for now.) > For instance, websites are big these days on asking for login > information for webmail clients to pull down contacts. What if an > informal protocol were developed for exchanging contact information? > Then, let's say I'm on Google Voice and want to call a number from my > address book (which may be run by an unrelated company). Google Voice > checks to see if I have a window open that identifies itself as an > address book, sends it a MessagePort, and displays an "add from > address book" button next to the phone number field. When I click the > button, the address book's UI changes to indicate that it's ready for > me to pick a phone number to send back to Google Voice. > > The same concept could apply to a password manager. An informal > protocol would let login pages broadcast their existence to other > windows and and if the user happens to have a web-based password > manager open, it could answer the request and send back credentials. > > I'm not great at coming up with use cases, but messaging between > separate top-level browsing contexts with different origins isn't > covered by the current APIs, and it's a broad enough category that > more-creative developers will want it once they realize that message > passing exists at all. I think the experience would be better using a shared worker for this, to be honest. You don't want to have to pop up a new window if the user doesn't yet have one for the contacts window, or something like that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Inter-window communication beyond window.postMessage()
On Mon, 14 Sep 2009, Jeremy Orlow wrote: > On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Inter-window communication beyond window.postMessage()
> On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson wrote: > > 4. Open a SharedWorker and send a MessagePort to the other window. I'm not too familiar with shared workers, but I read through the spec and it looks like they suffer from the SOP (as Drew mentioned). (LocalStorage also suffers from this, I shouldn't have included it in the original post.) > How do you know there's a Window to get a hold of if you don't have a hold > of it already? You don't. What's common among the use cases for this kind of inter-window communication is that you are trying to talk to windows which may have been around longer than you or were created after you. If the call fails or you get no response, handle it (tell the user, open the window, or do nothing.). > 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? On Mon, Sep 14, 2009 at 8:57 PM, Jeremy Orlow wrote: > 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. The original case that made me start exploring these APIs was a "stuff browser" that I'm working on (think address book). The browser stays open (as a popup) and can be used alone, but other pages should be able to ask it to navigate to a specific record. A shared worker would actually work quite nicely in this situation, but wouldn't work at all across-domains. For instance, websites are big these days on asking for login information for webmail clients to pull down contacts. What if an informal protocol were developed for exchanging contact information? Then, let's say I'm on Google Voice and want to call a number from my address book (which may be run by an unrelated company). Google Voice checks to see if I have a window open that identifies itself as an address book, sends it a MessagePort, and displays an "add from address book" button next to the phone number field. When I click the button, the address book's UI changes to indicate that it's ready for me to pick a phone number to send back to Google Voice. The same concept could apply to a password manager. An informal protocol would let login pages broadcast their existence to other windows and and if the user happens to have a web-based password manager open, it could answer the request and send back credentials. I'm not great at coming up with use cases, but messaging between separate top-level browsing contexts with different origins isn't covered by the current APIs, and it's a broad enough category that more-creative developers will want it once they realize that message passing exists at all.
Re: [whatwg] Inter-window communication beyond window.postMessage()
On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson 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.
Re: [whatwg] Inter-window communication beyond window.postMessage()
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? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Inter-window communication beyond window.postMessage()
Agreed - I've always felt like having to have a reference to a window would be an obstacle. I feel obliged to point out that cross-domain SharedWorkers might be another option for two completely unrelated windows to interact, although the suggestions I've heard for APIs for x-domain access seem to center around CORS, which may or may not be sufficient for this type of case. -atw On Mon, Sep 14, 2009 at 7:36 AM, 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. > > 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? >
