Chiron JavaScript Google Group

Re: [serverjs] Lunch, San Francisco Bay Area, June 27

2009-06-09T15:26:16Z

I'm in. I have never been able to resist an invitation to discuss cetacean
dental hygiene.

--
Cheers,
--MarkM

Lunch, San Francisco Bay Area, June 27

2009-06-09T08:43:55Z

I'll be in the Bay Area in a few weeks. If anyone would like to meet
up on Saturday, June 27th to confabulate on SSJS, modules, or cetacean
dental hygiene, I'm planning to meet at least Tom for lunch somewhere
between Redwood City and Mountain View.
Kris Kowal

Re: Asynchronous module loading

2009-05-31T18:52:14Z

Can you refer me to some info about promise-based architecture?
I have specific ideas about what I want the final system to be able to
do, but there is a lot of room for how it is implemented underneath.
Our discussion has given me some ideas about other possibilities. With
FireWidgets I hope to explore what can be done by loading dynamic

Re: Asynchronous module loading

2009-05-31T06:46:51Z

On Sat, May 30, 2009 at 8:33 PM, Christoph Dorn
I think you need a promise-based version of modules.js, but
unfortunately this means you won't be server-js, narwhal, or chiron
compatible in short order. Since I'm likely to need to do such a
thing eventually (although probably as a compilation target), and

Re: Asynchronous module loading

2009-05-31T03:33:31Z

I have been following the ServerJS discussions somewhat although much
of it is over my head and too low level for my interests. I am glad it
is resulting in some nice libraries like chiron and Narwhal.

I looked at Narwhal as well before picking chiron. Now that I am
further along with my prototype I am revisiting this decision. Narwhal

Re: Asynchronous module loading

2009-05-30T03:11:57Z

On Fri, May 29, 2009 at 3:41 PM, Christoph Dorn
Thanks for considering Chiron. I've been participating in a project
to construct a standard library for JavaScript that's presently called
"ServerJS" [1]. The version of Chiron you're working with was
constructed to conform to the Securable Modules [2] proposal that Ihab

Asynchronous module loading

2009-05-29T22:41:02Z

I am in the process of incorporating chiron into my own project
(Firefox Extension) to provide module loading capabilities and a
comprehensive set of base modules.

The extension creates sandboxes (XUL:browser) for given origin domains
and inserts chiron as well as app code into the sandboxed page.

Re: An idea about creating sandboxes.

2009-01-20T03:53:08Z

Alright. Let's leave the specification alone in this regard, keeping
the capability namespace separate from the module namespace.
So, this leaves the following issues unresolved:
* we don't yet have acceptable syntactic sugar for bringing
capability objects into local scope. We do have a salty syntax (var

Re: An idea about creating sandboxes.

2009-01-20T03:25:37Z

Agreed.
Agreed.
So this pre-populates the sandbox with an existing (moduleId =>
moduleInstance) map. Without reference to the @params issue yet, let's
consider this in isolation. It is certainly a provocative idea.
Consider the case where the stuff within the sandbox is using 2
modules (call them Widget.js and Color.js) that expect capabilities --

Re: Jacaranda and modules

2009-01-20T01:06:46Z

Haven't read up on everything but --
I think it's more like --
* "internal module representation" -> module function
Ihab

Re: Jacaranda and modules

2009-01-19T21:03:30Z

Are Jacaranda parse trees purple in Spring?
I think that the definitions here closely resemble our specification.
[link]
(Jacaranda -> ES Module Proposal)
* "module name" -> "module identifier"
* "module definition" -> "module text"
* "internal module representation" -> an object that contains the

Jacaranda and modules

2009-01-19T18:17:24Z

Hi folks,
Jacaranda is a statically verifiable secure JavaScript variant by
David-Sarah Hopwood (cc:'d). The following is the latest complete spec

An idea about creating sandboxes.

2009-01-17T05:26:05Z

Ihab,
I think we've agreed that the "require" object is a sandbox, which
closes over and contains a "load" function, which can safely pass from
parent to child sandbox without leaking capabilities since it only
renders module constructor functions, and a params object which
contains capability objects that the sandbox creator must explicitly

Re: Imports vs. loaded modules

2009-01-15T22:01:41Z

I think we should use different syntax, and I recommend the *provisional*
use of --
@param foo
for the sandbox slurping, vs. various forms of "import" or what not for the
module importing. The advantage of "@param" is that it is so ugly we *must*
revisit it in favor of something else. :)
I liked your summary of our call; thank you *so* much for that!

Re: Imports vs. loaded modules

2009-01-15T21:44:36Z

That's a fine place to start. Do you recommend a provisional syntax
for the distinction? Does this imply that we should use a completely
distinct syntax for sandbox slurping and module importing, or that we
should partition the name spaces for a single "from import as
using/with" syntax?
Kris
P.S. - the context for this thread is that Ihab and I had a phone call