httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <graham.dumple...@gmail.com>
Subject Re: Some ramblings on httpd config
Date Wed, 10 Jun 2009 01:28:29 GMT
2009/6/9 Akins, Brian <Brian.Akins@turner.com>:
> On 6/5/09 11:31 PM, "Graham Dumpleton" <graham.dumpleton@gmail.com> 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.

Well, I believe that separation already exists. How you would do
things in each context would be different. See mod_perl for example:

  http://perl.apache.org/docs/2.0/api/Apache2/PerlSections.html

How you write its configuration stuff is quite different to an actual handler.

> 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:

Except that for handler the calculation is more dynamic and not driven
through static defined data structures setup in configuration phase.

> 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

Huh, are you sure you can't do that now somehow. The vhost module uses
translate name hook so if you use LuaHookTranslateName I would presume
it would be possible to do something equivalent in 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')

Again, are you sure there aren't already ways of doing that with
mod_lua. Setting up proxying is simple enough to do in mod_python and
would be possible with mod_perl as well. For mod_python see example
in:

  http://issues.apache.org/jira/browse/MODPYTHON-141

If mod_lua provides equivalent wrappers for request object, would be
done in same way.

> (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.

Getting a bit confused here. You acknowledge you know about request
processing phases, but at the same time say you would like to see
stuff that I would have thought was already possible.

Do not I haven't used mod_lua/mod_wombat, so maybe it doesn't give you
level of programmability as modules such as mod_perl and mod_python.

> 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
>
>

Mime
View raw message