canmove, Confirmed users
1,953
edits
MDN/Archives/Kuma/Scripting: Difference between revisions
m
Jswisher moved page MDN/Kuma/Scripting to MDN/Archives/Kuma/Scripting
LesOrchard (talk | contribs) |
m (Jswisher moved page MDN/Kuma/Scripting to MDN/Archives/Kuma/Scripting) |
||
| (9 intermediate revisions by one other user not shown) | |||
| Line 71: | Line 71: | ||
== Miscellaneous notes == | == Miscellaneous notes == | ||
* Would like a relatively boring solution that matches core competencies | |||
** Components should have active existing communities | |||
** Try to stay close to dev team core-competencies | |||
** Try to make it sensible to host for care & feeding by IT | |||
* Switch from Lua to JavaScript basis | * Switch from Lua to JavaScript basis | ||
| Line 77: | Line 82: | ||
** node.js has an active community, works out-of-the-box | ** node.js has an active community, works out-of-the-box | ||
*** Maybe consider [https://github.com/zpao/spidernode SpiderNode], but only if we get benefits beyond not-invented-here purity | *** Maybe consider [https://github.com/zpao/spidernode SpiderNode], but only if we get benefits beyond not-invented-here purity | ||
* Or, do something ''with'' Lua? | |||
** [http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-01-30/Technology_report Wikipedia seems fond of Lua for ''their'' templates] | |||
* HTTP proxy service vs embedding JS | * HTTP proxy service vs embedding JS | ||
** Embedding JS in a Python app seems experimental, and outside webdev team core-competency | ** Embedding JS in a Python app seems experimental, and outside webdev team core-competency | ||
** HTTP is a webdev core-compentency, and has loose-coupling and RESTafarian benefits | ** HTTP is a webdev core-compentency, and has loose-coupling and RESTafarian benefits | ||
** Taming a code execution environment in its own process seems safer and more easily scaled | ** Taming a code execution environment in its own process seems safer and more easily scaled | ||
* Taming semi- or untrusted JavaScript code | * Taming semi- or untrusted JavaScript code | ||
** [http://nodejs.org/docs/v0.3.1/api/vm.html#vm.runInNewContext Built-in node.js sandboxing features] | ** [http://nodejs.org/docs/v0.3.1/api/vm.html#vm.runInNewContext Built-in node.js sandboxing features] | ||
| Line 86: | Line 96: | ||
*** Seems to have some more features than built-in node.js sandboxing | *** Seems to have some more features than built-in node.js sandboxing | ||
*** timeouts, restricted method access, graceful errors | *** timeouts, restricted method access, graceful errors | ||
* Use standalone [https://github.com/visionmedia/ejs embedded JS templates] instead of literals embedded in script? | * Use standalone [https://github.com/visionmedia/ejs embedded JS templates] instead of literals embedded in script? | ||
** Employs code-in-markup instead of markup-in-code, and avoids the need for fancy compiler hijinx | ** Employs code-in-markup instead of markup-in-code, and avoids the need for fancy compiler hijinx | ||
** This is being used in other projects | |||
* Might [https://github.com/laverdet/js-xml-literal js-xml-literals] come in handy? | * Might [https://github.com/laverdet/js-xml-literal js-xml-literals] come in handy? | ||
** [https://github.com/laverdet/js-xml-literal/issues/2 I failed on my first attempt to install], so haven't seen this in action. | ** [https://github.com/laverdet/js-xml-literal/issues/2 I failed on my first attempt to install], so haven't seen this in action. | ||
** This seems experimental; no one else really seems to be using it yet | |||
* Should we get a compiler / language expert in on this for opinions? | * Should we get a compiler / language expert in on this for opinions? | ||
** This smells like dangerous excitement | |||
* Could we port DekiScript directly? (It's open source, right?) | * Could we port DekiScript directly? (It's open source, right?) | ||
| Line 115: | Line 132: | ||
* Plentiful and intelligent HTTP-based caching | * Plentiful and intelligent HTTP-based caching | ||
' | === Prototype === | ||
lorchard has started work on a prototype in node.js: | |||
* https://github.com/lmorchard/kumascript | |||
=== Flow sketch === | |||
Here is a rough sketch of the process and network flows involved in this proposed solution: | |||
[[File:Kumascript.png|1000px|Kuma script flow]] | |||
More notes: | |||
* If the caching works right, we should be able to almost never load & compile templates unless they're edited. (Cache invalidation? HEAD requests before GET requests?) | |||
* When a Kuma wiki page is edited, the last-cached KumaScript response is discarded. | |||
* To support preview functionality, we can accept HTTP POST of arbitrary page source at the start of the KumaScript flow. Not cached, which is a feature. | |||
=== Code samples (imaginary) === | === Code samples (imaginary) === | ||
| Line 172: | Line 203: | ||
** How restrictive do we need to be? (ie. is trusting a certain set of authors enough?) | ** How restrictive do we need to be? (ie. is trusting a certain set of authors enough?) | ||
** How restrictive is DekiScript? | ** How restrictive is DekiScript? | ||
* Options inside node.js | * Options inside node.js | ||
** [http://nodejs.org/docs/v0.3.1/api/vm.html#vm.runInNewContext node.js has sandboxing out-of-the-box] | ** [http://nodejs.org/docs/v0.3.1/api/vm.html#vm.runInNewContext node.js has sandboxing out-of-the-box] | ||
** There's also [http://gf3.github.com/sandbox/ Sandbox] | ** There's also [http://gf3.github.com/sandbox/ Sandbox] | ||
* Options for host running node.js | * Options for host running node.js | ||
** No filesystem access at all (chroot?) | ** No filesystem access at all (chroot?) | ||