[e-lang] [Caja] Re: setTimeout (attn MarkM)
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
>> Domita to get its tameSetTimeout, or do my own?
> You should extract the tameSetTimeout wrapping from Domita (or do a
> 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