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. ~Jorge On Tue, Jun 9, 2009 at 2:49 PM, Akins, Brian<[email protected]> wrote: > On 6/5/09 11:31 PM, "Graham Dumpleton" <[email protected]> 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 == 'www.foo.com' then > .... > elseif r.hostname =~ /www\d.bar.[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 mod_lua.so > 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 mod_proxy.so > LoadModule proxy_http_module mod_proxy_http.so > .... > 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 > >
