On Sun, 27 Jan 2013, Jack (Zhan, Hua Ping) wrote:
>
> The postMessage design outlined in the W3C document edited by Ian
> Hickson is not good! The design of the cross document messaging by Ian
> Hickson (Google, Inc.) is very bad. Even the last version is not good
> either.
:-(
> The design can be sketched here as follows.
>
> The sender:
> var o = document.getElementsByTagName('iframe')[0];
> o.contentWindow.postMessage('Hello world', 'http://b.example.org/');
>
> The receiver:
> window.addEventListener('message', receiver, false);
> function receiver(e) {
> if (e.origin == 'http://example.com') {
> if (e.data == 'Hello world') {
> e.source.postMessage('Hello', e.origin);
> } else {
> alert(e.data);
> }
> }
> }
>
> This design was messed up by pulling "origin" (a word that some people
> put too much attention more than should).
Can you elaborate on what you mean by "pulling" in this sentence?
> Even worse, it requires "o.contentWindow", this is really no
> professional sense. Because of this design, if I open two tabs with the
> same url http://www.google.com/ they are not able to communicate.
If you need to communicate between two otherwise unrelated tabs, there are
basically two solutions: a shared worker, or a broadcast mechanism. The
latter isn't currently specced, but discussion on how to do it is here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22628
You can also currently fake this using the 'onstorage' event.
> My better proposal
>
> the sender:
> window.postMessage(messageObject,targetDomain optional,windowIDs optional);
>
> Either targetDomain or windowIDs should present.
> I propose to use ID rather than name (though window can have a name),
> since window.name is not required to be unique within the browser.
This is basically a broadcast mechanism, right.
One things that would be useful in making progress on this would be more
use cases, in particular use cases where it's important to be able to
respond after a broadcast.
There's basically only one use case in the bug above, namely informing
other windows of a state change (e.g. user logged in). This can currently
be done using "onstorage" and that could arguably in fact be a sufficient
solution (since for a "change" notification, there's no need to respond,
and it's typically stored state that has changed).
Cheers,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
