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.
We are looking at particular types of modules that can meet
requirements like:
1. A way to build trusted modules where module communication or access
to a module api
is granted within a trusted group.
2. A way to define visibility within a module's API such as private,
privileged, public modifiers
for a modules properties and methods.
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.
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.
5. Something that facilitates minimal cajoling or whitelisting which
may be compatible with caja's module definition.
6. A way to introduce prototypical inheritance so code reuse can be
facilitated among modules without violating 1.
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.
On Sep 10, 1:08 pm, [email protected] wrote:
> Hi there,
>
> On Thu, Sep 10, 2009 at 12:09 PM, kkasravi <[email protected]> wrote:
> > You had mentioned that a caja module was in the works (or committed)
> > that you would document. I was wondering if/when that documentation
> > would be available.
>
> I think you're talking about our module system that Ziqing Mao worked
> on. It's pretty usable at the moment. Documentation in a few weeks.
>
> Meanwhile, if you have a use case, please describe and I will be happy to
> help.
>
> Ihab
>
> --
> Ihab A.B. Awad, Palo Alto, CA
