W3C home > Mailing lists > Public > public-dap-commits@w3.org > May 2011

dap commit: first pass for feedback

From: Mercurial notifier <cvsmail@w3.org>
Date: Fri, 27 May 2011 10:10:44 +0000
Message-Id: <E1QPu0C-0007zW-9i@mcbain.w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 May 2011 10:10:47 GMT