http://codereview.appspot.com/11948/diff/8/9 File doc/html/compiledModuleFormat/index.html (right): http://codereview.appspot.com/11948/diff/8/9#newcode118 Line 118: <td><code class="prettyprint">execute</code></td> On 2009/01/22 17:39:28, MarkM wrote:
Based on reading the html without the css, you should add a valign="top" to your left column headings. I don't know if this is really needed
given your
css.
It isn't. But added anyway for standalone readability. TD valign defaults are a constant pain in the neck for me. :( http://codereview.appspot.com/11948/diff/8/9#newcode135 Line 135: <td><code class="prettyprint">cajoledDate</code></td> On 2009/01/22 17:39:28, MarkM wrote:
Why is the cajoledDate required? I think it should be optional.
At this point we're taking a best guess at the fields ahead of time, so my first inclination is to just say "ok" to all feedback. I'm really most interested in getting the format and keeping things simple. That all said, I guess making it optional means a cajoler can be implemented in a secure sandbox where it does not have access to the date, thus helping ensure that it is deterministic. So => changed to 'optional'. http://codereview.appspot.com/11948/diff/8/9#newcode160 Line 160: literal containing the text of the file. The text is escaped such that On 2009/01/22 17:39:28, MarkM wrote:
Even initially, I think we should somehow make an allowance for the
cajoler to
instead provide URLs from which the original source can be fetched,
rather than
shipping the original source directly.
This all depends on what the "original source" is used for. Typically, it is used for debugging. Given the size of the line-by-line debugging information, it's not clear to me that the original source will cause enough of a blowup of the module size to be worth bothering. Plus, including the literal original source ensures that the server does not depend on the stability of outside URLs for correctness of the debugging. So really => we are debugging (so to speak) the *debugging* experience. Do you still think this is worth pursuing any further? http://codereview.appspot.com/11948/diff/8/9#newcode180 Line 180: the <code>cajita.manifest()</code> function.</td> On 2009/01/22 17:39:28, MarkM wrote:
calling the caja.manifest() function [with a static JSON literal]. It would not work to call it with an expression that needs to be
evaluated,
since the whole point is to enable the manifest to be obtained without
(or prior
to) calling the module function.
I assume the alternative you propose is for the cajita.manifest() argument to be a string literal? Since we parse the program, we can hoist the parse tree generated by the argument of cajita.manifest() one level of instantiation upwards into the module envelope (after checking that it is JSON, which includes making sure that it has no references to external variables). Making it part of the parsed program allows us to do this checking more easily, and allows programmers to use their native syntax highlighters and what not to write the stuff. http://codereview.appspot.com/11948/diff/8/9#newcode185 Line 185: <div class="note">TODO: Move support for the "assumed-safe static path" information On 2009/01/22 17:39:28, MarkM wrote:
The right place for this is in the variable metadata above, where you
already
say "corresponding value is some JSON data providing meta-information
about the
module's expectations regarding that variable." The assumed-safe
static path
info is such an expectation.
Done. http://codereview.appspot.com/11948
