On Tue, Jun 30, 2009 at 4:25 PM, Brion Vibber<brion(a)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?