https://bugzilla.wikimedia.org/show_bug.cgi?id=59101
Brad Jorsch bjor...@wikimedia.org changed:
What|Removed |Added
Priority|Unprioritized |Lowest
--- Comment #1 from Brad Jorsch bjor...@wikimedia.org ---
JavaScript was considered during the creation of Scribunto, both V8 and Rhino.
But Lua turned out to be better suited than either.
The main pro for either JS engine was that JavaScript is likely more familiar
to our users than Lua. Problems with V8 include:
* Lack of documentation on embedding.
* Unclear whether embedding will continue to be supported upstream.
* Lack of a memory allocation hook, making it difficult to prevent
poorly-written or malicious scripts from overrunning memory limits.
* Huge standalone binary.
Problems with Rhino include:
* Written in Java.
* Impossible to embed in PHP, meaning that WMF wikis would have to use slow
IPC.
* Very slow startup. This could be mitigated by running as a daemon, but...
* Enforcing time and memory limits would require killing the external process,
necessitating another slow startup.
Either way, JavaScript didn't seem likely without a lot of effort.
On the other hand, about the only con with Lua is that it would be relatively
unfamiliar to most of our users. Pros include:
* Designed for embedding, with detailed documentation.
* Includes easy hooks to limit memory and CPU time usage.
* Standalone binary is small and fast. And a JIT is available if more speed
were needed.
* Easy to sandbox, with no odd globals.
If someone were to come along with a well-done patch to integrate a JavaScript
engine we'd likely review it when time permitted, but it's unlikely that we're
going to encourage anyone to spend time on it or prioritize it in any way. Lua
is already here and is already being learned by the community.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
