Hi there,
On Thu, Sep 10, 2009 at 4:47 PM, kkasravi <[email protected]> wrote:
> Yes, Ihab that's correct. Just to confirm my understanding of what the
> the caja module system does...
> The module system is what cajoled code is wrapped by which exposes
> particular apis,
> freezes the wrapped code, etc. in other words implements the
> capability model.
That's a rough idea yes. :) The cajoler compiles code into Caja
modules. The module system that Ziqing Mao built provides access to
these modules from code running within Caja, ensuring that the modules
do not leak authority. In other words, if I write Caja code and say:
var m = load('foo/bar/baz');
then the result of this, "m", is a module object which does not in
itself carry any authority. It is just code, and Caja guarantees it is
just code. It is not connected to anything elsewhere in the system.
Think of it as a JavaScript function with no free variables. I can
instantiate this module like so:
var anObject = /* some object ... */;
var instance = m({ a: 3, b: 4, c: anObject });
assuming that the module takes parameters "a", "b" and "c", and the
result will be an instance of the module. This instance is only
connected to the outside world via what I passed in as "a", "b" and
"c"; specifically, since "a" and "b" are just numbers, only the value
of "c", the object "anObject", provides any communication between the
instance of the module and the outside world.
> 1. A way to build trusted modules where module communication or access
> to a module api is granted within a trusted group.
You are responsible for deciding which modules are or are not trusted.
Given one of these trusted modules, you can instantiate it with
communication channels to precisely whatever you want; no more and no
less.
> 2. A way to define visibility within a module's API such as private,
> privileged, public modifiers for a modules properties and methods.
The return value of a module is the only value which is accessible to
the client of the module. All else in the module is private. The last
expression in the module is considered the "return value" of the
module. So the module I loaded earlier could look like:
function addA(x) { return x + a; }
function multiplyB(x) { return x * b; }
cajita.freeze({
doit: function (x) { c.setValue(addA(multiplyB(x))) }
});
Notice how this code has 3 free variables, "a", "b" and "c". Notice
how it expects "a" and "b" to be numbers, and "c" to be an object with
a "setValue" method. So now the API of "instance" I showed earlier
would be:
instance.doit(5);
which would cause "anObject" I showed earlier to have its "setValue"
called with a value of 23.
> 3. A way to define type metadata so that a modules internal and
> external types can be type checked. This would allow typechecking to
> occur for documentation generation and within js editors to reduce
> coding errors.
JS has no type system per se, and Caja does not add one.
> 4. A way to introspect into a module to build various runtime data
> such as types, instances, methods, events,
> etc. Introspection would be considered a privileged operation.
See #3.
> 5. Something that facilitates minimal cajoling or whitelisting which
> may be compatible with caja's module definition.
The cajoling service (a simple REST API on
http://caja.appspot.com/cajoler) will cajole arbitrary code which fits
the Caja input requirements.
> 6. A way to introduce prototypical inheritance so code reuse can be
> facilitated among modules without violating 1.
Valija supports prototypical inheritance. We have not tried it
*between* modules yet.
> 7. A way to properly encapsulate state within the module including
> closures so that state modifications can be controlled or gated.
> This should consider the ecma 5 property descriptors, sealing,
> freezing, etc.
We do not implement ECMAScript 5 property descriptors yet, but there
is the cajita.freeze() operation which freezes an object.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
