W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: New full Unicode for ES6 idea

From: Brendan Eich <brendan@mozilla.org>
Date: Sun, 19 Feb 2012 11:58:38 -0800
Message-ID: <4F41546E.60800@mozilla.org>
To: "Mark S. Miller" <erights@google.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, mranney@voxer.com, es-discuss <es-discuss@mozilla.org>
Brendan Eich wrote:
> My R2 resolution is not specific to any engine, but I have hopes it 
> can be accepted. It is concrete enough to help overcome 
> large-yet-vague doubts about implementation impact (at least IMHO). 
> Recall that document.domain setting may have to split a merged 
> same-origin window/frame graph, at any time. Again implementation 
> solutions vary, but this suggests cross-window mediation can be 
> interposed lazily.
>
> Another point: HTML5 WindowProxy (vs. Window, the global object on the 
> scope chain) exists to solve navigation-away-from-same-origin security 
> problems. Any JS that passes strings from one window to another must 
> be using a WindowProxy to reference the other. There's a mediation 
> point too.

IOW, whether there' s a heap/compartment per global is not critical (but 
if there is, then strings are already copied and could be transcoded as 
to their meta-data distinguishing non-BMP+UTF16-aka-full-Unicode from 
bad-ol'-90s-UCS2). The cross-window mediation via WindowProxy is.

The flag bits I mentioned could be combined: 1 flag bit for both 
non-BMP-chars-in-this-string-*and*-full-Unicode-BRS-setting-in-effect-for-its-global.

/be
Received on Sunday, 19 February 2012 19:59:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC