- From: Mercurial notifier <cvsmail@w3.org>
- Date: Fri, 27 May 2011 10:10:44 +0000
- To: public-dap-commits@w3.org
changeset: 22:e3e3bf71a7e5
tag: tip
user: Robin Berjon <robin@berjon.com>
date: Fri May 27 12:10:39 2011 +0200
files: proposals/request-feature/Overview.html
description:
first pass for feedback
diff -r fdd8a2141c4c -r e3e3bf71a7e5 proposals/request-feature/Overview.html
--- a/proposals/request-feature/Overview.html Fri May 27 11:06:40 2011 +0200
+++ b/proposals/request-feature/Overview.html Fri May 27 12:10:39 2011 +0200
@@ -34,6 +34,7 @@
</p>
<p class='note'>
This document is currently more of a sketch of a proposal than a properly defined specification.
+ The terminology is loose in parts, and requirements need a fair amount of tightening.
</p>
</section>
<section id='sotd'>
@@ -303,14 +304,39 @@
<section id='modules'>
<h2>Containing Access</h2>
<p>
-
+ The global scope in each module script is a proxy to the main scope such that the many host-defined
+ properties of <code>window</code> are available. However, script-defined properties are restricted to their
+ respective scopes.
</p>
- <!--
- XXX
- - mostly reference
- - can't write to these from the main scope
- - can always shoot yourself in the foot, but it's harder
- -->
+ <p>
+ The one addition to the module scope is the <code>exports</code> attribute, which is an empty object
+ which the module can modify in order to make functionality available to requiring scopes. The <code>exports</code>
+ object functions as defined in [[!COMMONJS]].
+ </p>
+ <p>
+ Naturally, a module can still shoot itself in the foot and expose functionality that would open the
+ privileged features to XSS vulnerabilities, but it is nevertheless much less likely to happen by
+ mistake. The simplest way of shooting oneself in the foot in a module would be as follows:
+ </p>
+ <pre class='example'>
+ // assuming geolocation privileges have been granted
+ exports.geolocation = navigator.geolocation;
+ </pre>
+ <p>
+ It is, however, difficult to protect against active stupidity — we only endeavour to contain the more
+ passive kind here.
+ </p>
+ <p>
+ A sketchy IDL is provided below. Questions are open as to whether <code>WindowProxy</code> is the
+ proper interface to inherit with, and as to the best way of specifying the access behaviour to the
+ requesting scope <code>window</code>.
+ </p>
+ <dl class='idl' title='[NoInterfaceObject] interface ModuleScope : WindowProxy'>
+ <dt>readonly attribute Object exports</dt>
+ <dd>
+ This empty object can be freely assigned to in order to define the module's interface.
+ </dd>
+ </dl>
</section>
<section class='appendix'>
<h2>Acknowledgements</h2>
Received on Friday, 27 May 2011 10:10:46 UTC