[e-lang] [Caja] Re: setTimeout (attn MarkM)

[Mark S. Miller]

On Fri, Jul 3, 2009 at 6:13 PM, Kevin Reid <kpreid at mac.com> wrote:

>
> [CCed to e-lang for relevance to capability-design discussion; use care
> when replying]
>
> On Jul 3, 2009, at 20:00, Mark S. Miller wrote:
>
>  On Fri, Jul 3, 2009 at 4:02 PM, Kevin Reid <kpreid at mac.com> wrote:
>>
>>  I find that callPub of setTimeout crashes on Firefox. Should I
>>> instantiate
>>> Domita to get its tameSetTimeout, or do my own?
>>>
>>
I've failed to reproduce that error by guessing. Could you tell/send me what
I need so I can reproduce this error? Thanks.



>
>> You should extract the tameSetTimeout wrapping from Domita (or do a
>> similar
>> one on your own), so that it'll work server side as well, where there is a
>> built-in setTimeout but not the rest of what Domita assumes.
>>
>
> 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.


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.

(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.)




> 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.
>

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.



>
>  What should a client app of my library (which needs deferred execution) be
>>> expected to provide me?
>>>
>>
>> An uncajoled client? I think I don't the question.
>>
>
> 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.
>
> How should Caja-CapTP expect to be provided its necessary authorities?
>
> Input format: Assume they're present by individual names in the imports? A
> single record in the imports? A powerbox object?
>
> 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?
>
> In the specific example of setTimeout, where should the wrapper live?
>

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:
* access to the global object,
* the ability to manipulate untamed properties and invoke untamed methods
(such as global.setTimeout()),

// uncajoled code
var powerbox = cajita.freeze({
    getGlobal: function() { return global; },
    readUntamed: function(obj, name) { return obj[name]; },
    callUntamed: function(obj, name, args) { return obj[name].apply(obj,
args); },
    ... similar s/Pub/Untamed/ access functions ...
};

I like the idea of writing a separate uncajoled script that
* sets up the above powerbox
* calls setNewModuleHandler (or similar) to arrange to
** provide the powerbox to the next module loaded.
** revert the newModuleHandler so that this power is not provided to later
modules, unless the first module specifies otherwise.

Notice that this really is as powerful as eval, since it gives access to
eval:

    // cajita code
    var global = powerbox.getGlobal();
    powerbox.callUntamed(global, 'eval', [computedString]);

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.

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.

-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20090703/9d8fa886/attachment.html