httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorge Schrauwen <>
Subject Re: Some ramblings on httpd config
Date Tue, 09 Jun 2009 13:32:02 GMT
As long as the current system isn't replaced by an entire runtime like
program approach I'd be okay with it.

But why not take it a step further than just lua?
Wouldn't it be possible to expose a standardized set of commands,
functions, objects, whatnot to any language?

That start with mod_lua as the initial implementation but if at a
later date someone makes mod_lisp/mod_java/.. they all share about the
same objects where just the syntax would be different. Also the glue
would then also extend to not just lua.

That would also help to make it documenting it language independently
more doable. (wow thats a word?)

you could then talk about a "request" object having properties x,y and
z and it doesn't matter if you manipulate it via lua,java,perl

Then again this would probably cause a whole lot of overhead and would
force mod_lua to be rewriting a lot I guess.


On Tue, Jun 9, 2009 at 2:49 PM, Akins, Brian<> wrote:
> On 6/5/09 11:31 PM, "Graham Dumpleton" <> wrote:
>> This last example wasn't even related to driving configuration. It was
>> in practice an actual handler hook implementation for request
>> processing, not configuration phases.
> The way I see it, we have artificially separated configuration from request
> processing.  If you squint and tilt your head just right, you can see that
> virtualhosts today are really just syntactical sugar over the if/else logic
> inside of core:
> Some pseudo request processing code to do same thing:
>  if listening_port == 80 then
>     if r.hostname == '' then
>         ....
>     elseif r.hostname =~ /www\[org|net]/
>     end
>  end
> Of course this could be further hidden from users with
> macros/functions/libraries/modules...
> Now, on the practical side, do we completely ditch the current config
> system.  Part of me says yes, but I know that will be -1'd to death.  So,
> I'd just like the ability to do something like this:
> LoadModule lua_module
> Listen 80
> LuaRequestHandler /path/to/my/lua/handler.lua
> (or it can be inline <Lua> but have found that to be somewhat cumbersome)
> Because I don't want to rewrite mod_proxy in lua, it'd be nice to have just
> a little bit of glue that would allow me to use it in a more "scripty" sort
> of way:
> LoadModule proxy_module
> LoadModule proxy_http_module
> ....
>  require httpd.proxy -- provided by mod_proxy glue
>  p = httpd.proxy.get_url('http://blah')
> (Of course, that example could be handled like we do in mod_rewrite)
> Currently, we can sorta do most request processing in lua. (FWIW, do the
> request phases make any sense in a world where the entire request process is
> handled by a "script"??)  What is missing is the glue to the other, useful
> parts of httpd - like cache, mod_dbd, proxy, etc.
> Sure, one of us could hack together some example glue here and there, but
> until we as a whole "get" why this is useful/important, it will be just
> another list of patches waiting to be reviewed.
> --
> Brian Akins
> Chief Operations Engineer
> Turner Digital Media Technologies

View raw message