- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 19 Jun 2008 05:50:52 +0000 (UTC)
- To: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
- Cc: Sunava Dutta <sunavad@windows.microsoft.com>, "public-html-comments@w3.org" <public-html-comments@w3.org>, Chris Wilson <Chris.Wilson@microsoft.com>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
On Wed, 18 Jun 2008, Zhenbin Xu wrote: > > It is still the developer's decision to decide whether or not to treat > the Message as public (*) or private (targetOrign). The thing I don't > like with "*" is that people would start to want finer grain control. > E.g. *://example.com/, http://*.example.com/ Sure. We can just say no. :-) > The other issue is that this is different from other programming pattern > such as XHR.open, where username and password need to be provided if > needed. > Web developers need to be aware of the ramification of sending public > message. It is worth prominently calling out the example you have below > in spec. But forcing them to add a "*" smells redundant and inelegant. Sure, but I think it's worth it to bring the fact that it's a wildcard to the attention of the author. We _want_ this to smell bad, frankly. > The second thing I want to point out is that the TOC-TOU example below > is a by-product of the async model that was just added. With sync model, > source window cannot navigate away until postMessage returns. Well, even with the sync model you could have the receipt and the sending decoupled in various ways that lead to the same problem. I agree that it is excacerbated by the async model, but it's not exclusive to it. > As consequence of async model, postMessage is no longer a reliable way > of conversion -- one party of the conversion may be gone while the other > party is still trying to talk back. I feel this is going to severely > limit its usefulness. Why? If the parties want to talk, then they shouldn't navigate away from each other. That seems pretty simple. :-) > There are still things about the async model that I don't quite > understand, such as how to track the replies -- if 5 postMessge is > called consecutively, how to handle out-of-order reply? That's up to the pages that define their protocols -- but generally, handling out of order replies is a solved problem in computer science. You use sequence IDs, topics, explicit context, any number of solutions come to mind. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 19 June 2008 05:51:28 UTC