Issac Goldstand wrote:
Paul Querna wrote:
Akins, Brian wrote:
On 3/26/08 9:06 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available. Modern mod_rewrite
usage commonly looks like programming, but it's not designed as
a programming language. Result: confused and frustrated users.
This is what I had in mind when I suggested having <Lua> blocks of
code. No
need to invent a new language when a perfectly fine one exists...
+1, and embed Lua in the core, and a dozen problems just like this are
solved.
-0.5 PLEASE not in the core. Make mod_wombat a standard module and
part of the default moduleset, whatever, but let's not make more core
dependencies, please?!?
Why not?
I look at it this way: We are already making up a "fake" language in our
configuration file.
If I get voted down (which is still pretty likely especially if all the
pro-lua'ers will be at the hackathon, whereas I won't :)) at least
No decisions will be made at the hackathon that will not be reflected on
the mailing list.
consider trying to limit the embedded interpreter to the parent process
and preventing it from being inherited by the children, if possible (to
remove completely unnecessary bloating)
I think the right approach is to first change the internal configuration
API.
Make it a real API, not a series of callbacks with filepointers and
strings in them.
Once we have that, we can write language bindings for all of them, and
all languages are on an equal footing.
My personal belief is that Lua should be compiled into the core, and
enabled by default. This does not really mean a hard dependency.
I would *prefer* that it can still be compiled out, and yes, while it
would be hard to configure without a 'configuration provider',
alternatives could be written in any language, or even with XML input as
others have wanted for years, since we now fixed configuration to be an API.
-Paul
