On Tue, Jun 30, 2009 at 4:25 PM, Brion Vibberbrion@wikimedia.org wrote:
IMO by the time you've implemented your whitelisting parser you might as well just interpret it rather than eval()ing.
I don't think so. You'd only have to do the whitelisting once, on page save. After that you could just execute with no extra overhead. Even better, you could write it to a file and include() the file; this would be a huge win if you have an opcode cache. Of course, parsing PHP within PHP should be much easier than parsing another language within PHP: just use token_get_all() to do most of the work.
(And of course, eval() might be disabled on the server. :)
Does anyone actually do this? It would break a lot of major web apps, surely. If anyone does do this, it would still work if you could write to a file and then include it.
Looping constructs are also extremely valuable -- at a minimum in a foreach() kind of way.
Right, but we could live without them in an initial version. They could be added later.
It's not about "Wikipedia content", but about being able to grab things you see on another wiki and use or adapt them to your own needs. We get lots of questions from people trying to grab some particular template off Wikipedia to use on their own site for their own needs.
Sure. The point still holds. Some third parties would be unable to use Wikipedia templates, yes. But given the tangle of dependencies the major ones have, and how complicated they are, I'm guessing most small third-party wikis don't bother in the end anyway. Requiring exec() for full use of content is viable IMO.
Considering the amount of trouble people have getting texvc working, I wouldn't want to force that on people just to use templates.
The problem with texvc is installing dependencies and compiling it. A much better analogy is things like diff3 -- which we shell out to out of the box, with zero configuration, if they exist and shelling out works. (We'd probably want scripting off by default, of course, but we could require just a single config line.)
Python "comes with batteries included", which is to say it's got a huge standard library (most of which of course wouldn't be available in a restricted environment). Lua's bare interpreter of course wins in an embedded-shipping contest. :D
Yep, but that's a big advantage. It means Windows users don't have to do any extra work. It also lets us ensure a specific version is reliably available. Imagine Wikimedia using Python 2.6, and someone trying to run that on some shared host running Fedora 8 or God knows what, with Python 2.2 or something. (Someone actually came into #mediawiki a few months ago for help and it turned out their VPS was something like Fedora 7 or 8. And horribly overpriced at that!)
Hmm... it might be interesting to experiment with something like this, if it can _really_ be compiled standalone. (Linux binary distribution is a hellhole of incompatible linked library versions!)
I hadn't thought of libraries, you're right. It should work pretty reliably on Linux (and hopefully not be too much bigger) if it's statically linked, though, right?