On Fri, Jul 3, 2009 at 6:13 PM, Kevin Reid <span dir="ltr"><<a href="mailto:kpreid@mac.com">kpreid@mac.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
[CCed to e-lang for relevance to capability-design discussion; use care when replying]<div class="im"><br>
<br>
On Jul 3, 2009, at 20:00, Mark S. Miller wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, Jul 3, 2009 at 4:02 PM, Kevin Reid <<a href="mailto:kpreid@mac.com" target="_blank">kpreid@mac.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I find that callPub of setTimeout crashes on Firefox. Should I instantiate<br>
Domita to get its tameSetTimeout, or do my own?<br>
</blockquote>
</blockquote></div></blockquote><div><br>I've failed to reproduce that error by guessing. Could you tell/send me what I need so I can reproduce this error? Thanks.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
You should extract the tameSetTimeout wrapping from Domita (or do a similar<br>
one on your own), so that it'll work server side as well, where there is a<br>
built-in setTimeout but not the rest of what Domita assumes.<br>
</blockquote>
<br></div>
It is a little bit unfortunate that (due to the call error) (I assume) it is not possible to write the majority of the taming wrapper in Cajita, for robustness purposes. </blockquote><div><br>Yes. So-called "host" objects -- meaning objects outside the ES3 spec and
not implemented in JavaScript, such as DOM objects and setTimeout --
are allowed by the ES3 spec to have almost arbitrary behavior. Our
taming mechanism relies on some regularities of behavior that host
objects sometimes violate -- as the spec allows them to. Therefore,
we've generally taken the attitude that we should never expose these
objects directly to cajoled code, since we can't rely on the taming
mechanism to make them safe to handle.<br>
<br>
(Unfortunately, membraning the DOM without weak tables causes an
unsolvable GC problem, so we are considering very carefully taming
rather than wrapping the DOM. But we can ignore that for now.)<br>
<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Coming from E, I feel that Cajita lacks 'privileged env' facilities -- the ability to work with unsafe/untamed objects while standing within the capability-structured environment.<div class="im">
</div></blockquote><div><br>Good. I was hoping you'd push us in exactly this direction. We badly need to go there. Right now, the uncajoled code expresses too many policy decisions, rather than simply setting things up for a cajoled "main" module.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What should a client app of my library (which needs deferred execution) be<br>
expected to provide me?<br>
</blockquote>
<br>
An uncajoled client? I think I don't the question.<br>
</blockquote>
<br></div>
Caja-CapTP consists entirely of cajoled code. To function at all, it needs various authority such as setTimeout and network access. Therefore, there must be some privileged (= uncajoled, for now) loader which provides it that authority.<br>
<br>
How should Caja-CapTP expect to be provided its necessary authorities?<br>
<br>
Input format: Assume they're present by individual names in the imports? A single record in the imports? A powerbox object?<br>
<br>
Origin: Should Caja-CapTP expect each client to construct and supply the authority, or should Caja-CapTP provide an privileged-code file for clients to load uncajoled which provides its authority, or what?<br>
<br>
In the specific example of setTimeout, where should the wrapper live?<div><div></div></div></blockquote><div><br>Brainstorming here, let's think about what a full authority powerbox might look like, i.e., a privileged object whose API provides to its cajoled client all the authority available to uncajoled JS in that context. I think it would amount to two things: <br>
* access to the global object, <br>* the ability to manipulate untamed properties and invoke untamed methods (such as global.setTimeout()),<br><br>// uncajoled code<br>var powerbox = cajita.freeze({<br> getGlobal: function() { return global; },<br>
readUntamed: function(obj, name) { return obj[name]; },<br> callUntamed: function(obj, name, args) { return obj[name].apply(obj, args); },<br> ... similar s/Pub/Untamed/ access functions ...<br>};<br><br>I like the idea of writing a separate uncajoled script that<br>
* sets up the above powerbox<br>* calls setNewModuleHandler (or similar) to arrange to <br>** provide the powerbox to the next module loaded.<br>** revert the newModuleHandler so that this power is not provided to later modules, unless the first module specifies otherwise.<br>
<br>Notice that this really is as powerful as eval, since it gives access to eval:<br><br> // cajita code<br> var global = powerbox.getGlobal();<br> powerbox.callUntamed(global, 'eval', [computedString]);<br>
<br>It also provides all the power of ___ and setTimeout in the same way, since they are just global variables. This also allows the cajoled startup module to express further taming decisions.<br><br>An interesting test would be to use this powerbox to create a safe setTimeout wrapper from cajita code, and see how that compares with the current practice of creating the wrapper in uncajoled code. <br>
<br></div></div>-- <br> Cheers,<br> --MarkM<br>