httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <>
Subject Re: Some ramblings on httpd config
Date Wed, 10 Jun 2009 01:31:37 GMT
2009/6/9 Jorge Schrauwen <>:
> 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?

The standard objects are things like request_rec, server_rec etc etc.
Ie., Apache's own internal data structures. Modules such as mod_perl
and mod_python provide wrappers for these. The standardised set of
commands are the Apache and APR functions which are also wrapped.

Or are you talking about higher level functionality. A lot of higher
level functionality is I understand provided in modules associated
with mod_perl already. In other words, at the moment any higher levels
encapsulation of functionality up to the specific script language
module. Some provide more than others.


> 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.
> ~Jorge
> 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