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

Kevin Reid kpreid at mac.com
Fri Jul 3 21:13:35 EDT 2009

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

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

Kevin Reid                                  <http://switchb.org/kpreid/>

More information about the e-lang mailing list