Re: Some ramblings on httpd config
On 6/10/09 10:21 AM, "Dan Poirier" wrote: >> That sounds a whole lot like using the config as a runtime. > > I'm not sure I follow that. I do like that the config would still look > a lot like it does now, only more flexible. Even if we kept the same general syntax as now, if we introduce variables and if/else, then the "config" has to be "compiled" and "ran" at request time. (Glossing over a lot, I know.) Also, module would have to have some interface to accept the variables and conditionals. Also, we would have to basically write our own domain-specific language. My thought is rather than incrementally attempting to do this, we can just adopt an existing language that fits our needs - like lua. This adoption can be done incrementally, as well. Some examples of that, using a more complete version of mod_lua, have been mentioned. -- Brian Akins
Re: Some ramblings on httpd config
"Akins, Brian" writes: > On 6/10/09 8:52 AM, "Rich Bowen" wrote: > >> If we had a standard set of variables (like, say, HOSTNAME or whatever) that >> could be interpolated into config directives, as well as a standard way to do >> variable assignment and backreferences, that would solve a whole class of >> problems that are really pretty difficult right now. > > That sounds a whole lot like using the config as a runtime. I'm not sure I follow that. I do like that the config would still look a lot like it does now, only more flexible. -- Dan Poirier
Re: Some ramblings on httpd config
On 6/10/09 8:52 AM, "Rich Bowen" wrote: > Or something like that that's sufficiently like what we have now to be easy to > learn, but sufficiently different to be harder to get wrong, and a whole heck > of a lot easier to do dynamic vhosts. I think Lua (or whatever) could include enough "user friendly glue" to make something like that possible. > If we had a standard set of variables (like, say, HOSTNAME or whatever) that > could be interpolated into config directives, as well as a standard way to do > variable assignment and backreferences, that would solve a whole class of > problems that are really pretty difficult right now. That sounds a whole lot like using the config as a runtime. Hmmm, where have I heard that before ;) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
On Jun 9, 2009, at 08:49, Akins, Brian wrote: 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 As long as we're talking about exposing nifty syntax in the config ... I'd be content (at least briefly - I'm sure I could find something else to be discontent about) if virtual hosts were less baffling, or, at least, harder to get wrong. Something like: DocumentRoot /x/y DocumentRoot /var/vhosts/HOSTNAME CustomLog /var/log/HOSTNAME.log combined And perhaps something fancier regexey to encompass all of the magic that mod_vhost_alias does. Or something like that that's sufficiently like what we have now to be easy to learn, but sufficiently different to be harder to get wrong, and a whole heck of a lot easier to do dynamic vhosts. One of the other big complaints that comes up, in various ways, daily on IRC, is that there's no standard way to put variables in configuration directives. If we had a standard set of variables (like, say, HOSTNAME or whatever) that could be interpolated into config directives, as well as a standard way to do variable assignment and backreferences, that would solve a whole class of problems that are really pretty difficult right now. Of course, I say all of that being utterly ignorant of how this all works internally, so feel free to ignore me. Like I said before, I answer the "how do I" questions every day, and frequently find myself wondering why things that *sound* so easy are actually so very difficult. -- A poet more than thirty years old is simply an overgrown child. H. L. Mencken
Re: Some ramblings on httpd config
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.
Graham
> 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 == '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 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
>>
>>
>
Re: Some ramblings on httpd config
2009/6/9 Akins, Brian :
> 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.
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 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
>
>
Re: Some ramblings on httpd config
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 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 == '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 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
>
>
Re: Some ramblings on httpd config
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 == '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 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
Re: Some ramblings on httpd config
2009/6/6 Rich Bowen : > > On Jun 4, 2009, at 22:53, Graham Leggett wrote: > >>> This approach doesn't require any changes to httpd itself as the >>> ability to do this becomes a feature of just the module supporting >>> that scripting language, eg, mod_lua. The same could also be done for >>> other scripting languages. >>> >>> So, if your aim is to be able to do everything within the one Apache >>> configuration file, rather than out in separate scripts, this would >>> seem in part to satisfy the requirement. >> >> I like this. >> >> In theory, you could have a mod_java, or anything really. > > > As one of the folks who answers the "How Do I" questions every day, while > that would indeed be neato and nifty, it behooves us to pick a configuration > file syntax, not say "do it in whatever language amuses you." > > We've had configuration in Perl for years, but we don't push it because most > of our audience looks at us like aliens when we suggest it. The folks savvy > enough to use the Perl configuration can go find it and do it that way, and > can indeed do powerful things with it. > > But the vast majority of the folks that actually admin the server don't want > to be told to script their configuration in the programming language of > their choice. They want a howto recipe, and they want it to work without > having fiddle about with learning complicated syntax. > > I'd also humbly request that we *not* put "Lua" in the configuration > directives. If folks are configuring a virtual host, they aren't going to be > looking for directives starting with Lua*. Over the years we seem to have > moved from giving configuration directives whatever name sprang to mind, to > giving them function-based names that people will actually find in the > documentation. Let's not scrap that. Our users don't care that it's > implemented in Lua, and shouldn't have to care. 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 intent is not to replace current Apache configuration mechanism but leave it as is. Was just highlighting for the convenience factor, for simple stuff, scripting modules allowing handler implementations to be defined in the Apache configuration file itself rather than in a separate file/module. Whether a particular scripting module does that would be up to that module. No intention to change the core of Apache. Thus, you might have this ability for request handler phase hook implementations to be in configuration file with mod_lua, mod_wsgi, mod_python, mod_tcl, mod_other_scripting language. I don't use mod_perl, but If I remember correctly, mod_perl only allows this for configuration generation and not for request handler phase hook implementations as talking about here. Anyway, this would all be a power user thing and not the only way of doing things and most certainly kept away from inexperienced people. Graham
Re: Some ramblings on httpd config
Rich Bowen wrote: > > On Jun 4, 2009, at 22:53, Graham Leggett wrote: > >>> This approach doesn't require any changes to httpd itself as the >>> ability to do this becomes a feature of just the module supporting >>> that scripting language, eg, mod_lua. The same could also be done for >>> other scripting languages. >>> >>> So, if your aim is to be able to do everything within the one Apache >>> configuration file, rather than out in separate scripts, this would >>> seem in part to satisfy the requirement. >> >> I like this. >> >> In theory, you could have a mod_java, or anything really. > > > As one of the folks who answers the "How Do I" questions every day, > while that would indeed be neato and nifty, it behooves us to pick a > configuration file syntax, not say "do it in whatever language amuses you." > > We've had configuration in Perl for years, but we don't push it because > most of our audience looks at us like aliens when we suggest it. The > folks savvy enough to use the Perl configuration can go find it and do > it that way, and can indeed do powerful things with it. > > But the vast majority of the folks that actually admin the server don't > want to be told to script their configuration in the programming > language of their choice. They want a howto recipe, and they want it to > work without having fiddle about with learning complicated syntax. > > I'd also humbly request that we *not* put "Lua" in the configuration > directives. If folks are configuring a virtual host, they aren't going > to be looking for directives starting with Lua*. Over the years we seem > to have moved from giving configuration directives whatever name sprang > to mind, to giving them function-based names that people will actually > find in the documentation. Let's not scrap that. Our users don't care > that it's implemented in Lua, and shouldn't have to care. I think I made the same point a little earlier, you have no argument from me. The point being made above was that it is possible for people to plug in scripting languages into the server hooks themselves. This may allow the flexibility of configuration and operation that people are looking for, while leaving the core method of configuration alone. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Some ramblings on httpd config
On Jun 4, 2009, at 22:53, Graham Leggett wrote: This approach doesn't require any changes to httpd itself as the ability to do this becomes a feature of just the module supporting that scripting language, eg, mod_lua. The same could also be done for other scripting languages. So, if your aim is to be able to do everything within the one Apache configuration file, rather than out in separate scripts, this would seem in part to satisfy the requirement. I like this. In theory, you could have a mod_java, or anything really. As one of the folks who answers the "How Do I" questions every day, while that would indeed be neato and nifty, it behooves us to pick a configuration file syntax, not say "do it in whatever language amuses you." We've had configuration in Perl for years, but we don't push it because most of our audience looks at us like aliens when we suggest it. The folks savvy enough to use the Perl configuration can go find it and do it that way, and can indeed do powerful things with it. But the vast majority of the folks that actually admin the server don't want to be told to script their configuration in the programming language of their choice. They want a howto recipe, and they want it to work without having fiddle about with learning complicated syntax. I'd also humbly request that we *not* put "Lua" in the configuration directives. If folks are configuring a virtual host, they aren't going to be looking for directives starting with Lua*. Over the years we seem to have moved from giving configuration directives whatever name sprang to mind, to giving them function-based names that people will actually find in the documentation. Let's not scrap that. Our users don't care that it's implemented in Lua, and shouldn't have to care. -- If we only live, We too will go to sea in a Sieve,--- To the hills of the Chankly Bore!
Re: Some ramblings on httpd config
Graham Dumpleton wrote: > Since you are talking here about runtime decisions based on a specific > request, rather than auto generation of the static configuration in > once off phase, it almost sounds like all you need is a way of having > the lua code which would be associated with a specific handler in the > configuration file rather than having to be in a separate file. So, > instead of: > > LuaHookTranslateName lib/hooks.lua trans_name > > allowing something like: > > > function trans_name(r) > ... > end > > > This approach doesn't require any changes to httpd itself as the > ability to do this becomes a feature of just the module supporting > that scripting language, eg, mod_lua. The same could also be done for > other scripting languages. > > So, if your aim is to be able to do everything within the one Apache > configuration file, rather than out in separate scripts, this would > seem in part to satisfy the requirement. I like this. In theory, you could have a mod_java, or anything really. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Some ramblings on httpd config
2009/6/4 Akins, Brian : > On 6/4/09 8:14 AM, "Jorge Schrauwen" wrote: > >> Like Graham mentioned mod_macro can be of some use here. however since >> I'm looping in perl I may as well push the 4 lines needed to httpd >> instead of a one line macro replacemen. > > Okay, I'm not explaining my self well. I'm not just talking about > generating the internal configuration from lua (or xml, or macro, etc.) > > But actually "running" httpd using lua. The request handling is done in lua > - or rather driven by lua. > > See http://redmine.lighttpd.net/projects/lighttpd/wiki/AbsoLUAtion > > A side note: I think the vhost concept we have now is lacking. The > separation that we have just isn't necessary and makes some common tasks > hard. I'm not really willing to fight for this one though ;) I can "fake" > what I want if I can just load up a lua handler to handle the request from > post_read to handler. Since you are talking here about runtime decisions based on a specific request, rather than auto generation of the static configuration in once off phase, it almost sounds like all you need is a way of having the lua code which would be associated with a specific handler in the configuration file rather than having to be in a separate file. So, instead of: LuaHookTranslateName lib/hooks.lua trans_name allowing something like: function trans_name(r) ... end This approach doesn't require any changes to httpd itself as the ability to do this becomes a feature of just the module supporting that scripting language, eg, mod_lua. The same could also be done for other scripting languages. So, if your aim is to be able to do everything within the one Apache configuration file, rather than out in separate scripts, this would seem in part to satisfy the requirement. Graham
Re: Some ramblings on httpd config
Absolutely, but since it doesn't come with the product, most folks are never going to see it. Can we get Fabien to contribute it? On Jun 4, 2009, at 07:58, Graham Dumpleton wrote: 1. There are many and large and complex configurations out in the world. Which is exactly why I want/need a better way to do them. I'm currently using a template system to generate them. However I wind up with dozens (and dozens) of vhosts that sometimes only vary by a statement or too. Would mod_macro help. http://www.coelho.net/mod_macro/ Graham -- Just because your voice reaches halfway around the world doesn't mean you are wiser than when it reached only to the end of the bar. Edward R. Murrow
Re: Some ramblings on httpd config
On 6/4/09 8:14 AM, "Jorge Schrauwen" wrote: > Like Graham mentioned mod_macro can be of some use here. however since > I'm looping in perl I may as well push the 4 lines needed to httpd > instead of a one line macro replacemen. Okay, I'm not explaining my self well. I'm not just talking about generating the internal configuration from lua (or xml, or macro, etc.) But actually "running" httpd using lua. The request handling is done in lua - or rather driven by lua. See http://redmine.lighttpd.net/projects/lighttpd/wiki/AbsoLUAtion A side note: I think the vhost concept we have now is lacking. The separation that we have just isn't necessary and makes some common tasks hard. I'm not really willing to fight for this one though ;) I can "fake" what I want if I can just load up a lua handler to handle the request from post_read to handler. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
On 6/4/09 7:51 AM, "Dan Poirier" wrote:
> and having to write a program to
> implement mod_rewrite or a virtual host yourself.
Something like this would be trivial to do:
if prefix_match(r.uri, "/foo/") then
return do_redirect(r, "http://somewhere.else/";)
end
Okay, not a great example, but it's early here :) The fact that
conditionals are just *there* in lua would make some rewrite operations
easier. We could also provide plenty of helper stuff (written in lua,
probably).
rr = httpd.rewrite
rr.rule('/something(.*)', '/other$1')
-- in handler
x = rr.run( r )
if(x != DECLINED) then
return x
end
if r.env["something"] then
return proxy:request(r, "http://some.domain.com";)
end
Like I said, I'm not just thinking of lua as a config, but lua as the
"driver" of httpd. Or at least provide enough glue for some core modules to
allow us "advanced" users to do this. We may not need a whole lot of glue
to start with, a few useful ones:
serve_file(r, "/some/file/on/disk")
x = do_subrequest(r, uri) -- x could contain headers, bucket brigade (or
just a big string)
do_redirect(r, location, 301)
Also, it would be nice if we could redo the mod_lua lua-request_rec glue so
that other modules can "mixin" addition functionality:
require "httpd.util"
r:serve_file("/some/file"
r:redirect(location, 301)
I've been playing with that, but my lua-glue foo is weak. Something about
the way we are handling the metatable and __index doesn't like that.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Some ramblings on httpd config
On Thu, Jun 4, 2009 at 1:55 PM, Akins, Brian wrote: > On 6/3/09 7:50 PM, "Plüm, Rüdiger, VF-Group" > wrote: > >> 1. There are many and large and complex configurations out in the world. > > Which is exactly why I want/need a better way to do them. I'm currently > using a template system to generate them. However I wind up with dozens > (and dozens) of vhosts that sometimes only vary by a statement or too. > On this I completely agree! Currently say fetching 100+ hosts from a database that are basicly the same except domain, documentroot and maybe 3 options like has php, has cgi,.. is a PITA. mod_perl with database backend... works I guess but it's like taking a nice car, strip the engine and gut donkey and cram the engine in the donkey. Ok not what I wanted to write but can't describe it. Like Graham mentioned mod_macro can be of some use here. however since I'm looping in perl I may as well push the 4 lines needed to httpd instead of a one line macro replacemen. > A contrived example: > > -- lots of stuff > if r.hostname == "www.domain.com" then > -- a couple of things specific to this domain > elseif r.hostname == "www.domain2.com" then > ... > > > Of course, this example may could have a little lua glue to handle this > situation. > > > Also, I'm not just talking about lua being the config language, I want lua > to "drive" the httpd process. Ie, the above code gets ran on every request. > >> 2. I admit that some improvements are needed. How about an approach that >> allows >> to embed a macro / scripting language into the current configuration >> system >> that allows you to do more advanced things if you need to. > > If we provided enough glue within our modules for lua, this this would be > fairly easy. I already fake this a bit with mod_lua and handlers that do > most of the work. > -- > Brian Akins > Chief Operations Engineer > Turner Digital Media Technologies > > Maybe we're looking at it the wrong way? Why not go more modular with this as well? >From what I've understood from wrowe's explenation the internal config tree seems very flexible so why not create multiple ways to manipulate it? module register "parameters,blocks,..." with the internal config mangement thingy, front ends then configure the modules using those interfaces. It being a flat file, xml file, lua script, perl script,... having little relevance to httpd itself. Flat file would turn that info say for the command into something like Documentroot /some/path Lua format would turn that in something else, whilst an xml format way turn it into /some/path You could keep the current method for legacy use, implement an lua one for more advance use, xml one because somebody was bored and wanted it. Heck even a lolcode one because you could. even mixing could be possible, have some general stuff in flatfile, include a lua script to generate hosts which in its turn include a flat file with shared config for each host. Then again it would be hard to write documentation for this. Since "documenroot" could then have many ways to be set from a users POV :( so maybe not a great idea. But I'm just trowing out the whacky brain twists I have. Jorge
Re: Some ramblings on httpd config
2009/6/4 Akins, Brian : > On 6/3/09 7:50 PM, "Plüm, Rüdiger, VF-Group" > wrote: > >> 1. There are many and large and complex configurations out in the world. > > Which is exactly why I want/need a better way to do them. I'm currently > using a template system to generate them. However I wind up with dozens > (and dozens) of vhosts that sometimes only vary by a statement or too. Would mod_macro help. http://www.coelho.net/mod_macro/ Graham > A contrived example: > > -- lots of stuff > if r.hostname == "www.domain.com" then > -- a couple of things specific to this domain > elseif r.hostname == "www.domain2.com" then > ... > > > Of course, this example may could have a little lua glue to handle this > situation. > > > Also, I'm not just talking about lua being the config language, I want lua > to "drive" the httpd process. Ie, the above code gets ran on every request. > >> 2. I admit that some improvements are needed. How about an approach that >> allows >> to embed a macro / scripting language into the current configuration >> system >> that allows you to do more advanced things if you need to. > > If we provided enough glue within our modules for lua, this this would be > fairly easy. I already fake this a bit with mod_lua and handlers that do > most of the work. > -- > Brian Akins > Chief Operations Engineer > Turner Digital Media Technologies > >
Re: Some ramblings on httpd config
On 6/3/09 7:50 PM, "Plüm, Rüdiger, VF-Group" wrote: > 1. There are many and large and complex configurations out in the world. Which is exactly why I want/need a better way to do them. I'm currently using a template system to generate them. However I wind up with dozens (and dozens) of vhosts that sometimes only vary by a statement or too. A contrived example: -- lots of stuff if r.hostname == "www.domain.com" then -- a couple of things specific to this domain elseif r.hostname == "www.domain2.com" then ... Of course, this example may could have a little lua glue to handle this situation. Also, I'm not just talking about lua being the config language, I want lua to "drive" the httpd process. Ie, the above code gets ran on every request. > 2. I admit that some improvements are needed. How about an approach that > allows >to embed a macro / scripting language into the current configuration system >that allows you to do more advanced things if you need to. If we provided enough glue within our modules for lua, this this would be fairly easy. I already fake this a bit with mod_lua and handlers that do most of the work. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
Niklas Edmundsson writes: > Those who can't grasp lua probably couldn't grasp our current config > scheme either. I strongly disagree. There's a huge gulf between being able to describe a configuration with a few directives, and having to write a program to implement mod_rewrite or a virtual host yourself. I really don't want to spend the next however-many-years debugging not only users' configurations, but their programming as well. -- Dan Poirier
Re: Some ramblings on httpd config
Rich Bowen writes: > The directive, along with better documentation, would solve 50% of what > people use mod_rewrite for. A less painful way to configure dynamic virtual > hosts would solve another 15%. And a healthy dose of education about all the > gross misconceptions called "SEO" would solve the rest. > > Yes, we need some kind of macro thingy in the configuration. And while I think > that most of us reading this email thread can handle that thingy being Lua, I > honestly don't believe that the folks over on the users@ list can, unless it's > something that can be embedded into existing configurations, rather than being > the entirety of the configuration. If we can fix the biggest problems with the current configuration scheme, I think that's a powerful argument that we don't need to throw it out and invent a whole new one. As others have said, there's a huge amount of knowledge out there based on the current configuration scheme, and throwing all that out would be a shame. -- Dan Poirier
Re: Some ramblings on httpd config
Brian McCallister wrote: > I would like to see the *output* of configuration be a struct (of > structs), and the actual config files are never looked at again (until > reload). At that point we don't need to care how it is built, and we > can try using lua, vcl, xml, jelly, groovy, windows ini files, or > plists :-) > > I suspect (and, kind of, hope) lua will win. I looked at this a few years ago, and modularising the config shouldn't be difficult. Essentially the config is built by looping through tokens, and calling the config hook for each token. Right now, the tokens happen to be a single line in a file, but there is no need for it to be. The tokens could come from a piece of lua code building an array, or perl, or a flat file (like now), or LDAP (which was my interest at the time I looked at this), or XML, or whatever. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Some ramblings on httpd config
I would like to see the *output* of configuration be a struct (of structs), and the actual config files are never looked at again (until reload). At that point we don't need to care how it is built, and we can try using lua, vcl, xml, jelly, groovy, windows ini files, or plists :-) I suspect (and, kind of, hope) lua will win. -Brian On Wed, Jun 3, 2009 at 5:31 PM, Graham Leggett wrote: > Akins, Brian wrote: > >>> This does IMHO not address any of the problems users usually have and >>> that are mainly due to a lack of validation. >> >> First of all, I don't really care about "normal" users, to be honest. Admit >> it, I'm not the only one. However, I do know that we can't just break >> everything for them. > > While I see the benefits of allowing people to do powerful things with a > programming language configuration, I see far bigger downsides, not the > least of which is that suddenly end users need to learn a new > programming language. > > And it's not about how "easy" it is to learn a new programming language, > it is the fact that I have to learn the language at all. I just don't > have time to mess around. > > If you come up with a configuration syntax that can keep it simple for > most people, but allows you to plug in a configuration language for > those that need one, you're onto a winner. > > But if you try and fix one group of people's problems by causing > additional problems for another group of people, you've achieved nothing. > > Regards, > Graham > -- >
Re: Some ramblings on httpd config
Akins, Brian wrote: >> This does IMHO not address any of the problems users usually have and >> that are mainly due to a lack of validation. > > First of all, I don't really care about "normal" users, to be honest. Admit > it, I'm not the only one. However, I do know that we can't just break > everything for them. While I see the benefits of allowing people to do powerful things with a programming language configuration, I see far bigger downsides, not the least of which is that suddenly end users need to learn a new programming language. And it's not about how "easy" it is to learn a new programming language, it is the fact that I have to learn the language at all. I just don't have time to mess around. If you come up with a configuration syntax that can keep it simple for most people, but allows you to plug in a configuration language for those that need one, you're onto a winner. But if you try and fix one group of people's problems by causing additional problems for another group of people, you've achieved nothing. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Some ramblings on httpd config
2009/6/4 "Plüm, Rüdiger, VF-Group" : > 2. I admit that some improvements are needed. How about an approach that > allows > to embed a macro / scripting language into the current configuration system > that allows you to do more advanced things if you need to. > (OK, yes this proposal contradicts some of the downsides I mentioned in > 1.1. So I am not consistent here :-)). My memory could be rusty, but I thought mod_perl had a way of doing that already, at least for when mod_perl is being used. Thus, there is perhaps precedent for that unless I am going senile. Graham
Re: Some ramblings on httpd config
> -Ursprüngliche Nachricht-
> Von: Bertrand Mansion
> Gesendet: Mittwoch, 3. Juni 2009 22:35
> An: dev@httpd.apache.org
> Betreff: Re: Some ramblings on httpd config
>
> Lua can look like this :
>
> DocumentRoot = "/htdocs"
> ServerName = "www.example.com"
> VirtualHosts = {
> "www.example.com" = { DocumentRoot = "/example.com/htdocs" }
> }
I am not very enthusiastic about going for lua as the configuration
language and even the above example doesn't convince me.
But I might be very biased here, since I live well with the current
configuration
schema since about 9 years and I am used to it.
Furthermore I like mod_rewrite and I have no problems using it :-).
But apart from that two points:
1. There are many and large and complex configurations out in the world.
If we do such a drastic change in configuration IMHO we either need to
1.1 Allow both approaches for configuring the server (current one + lua),
which I guess will also increase user confusion, maintenance effort
and support effort.
1.2 Build a tool that converts over 90% of the current configurations
flawlessly into the new schema.
2. I admit that some improvements are needed. How about an approach that allows
to embed a macro / scripting language into the current configuration system
that allows you to do more advanced things if you need to.
(OK, yes this proposal contradicts some of the downsides I mentioned in
1.1. So I am not consistent here :-)).
Regards
Rüdiger
Re: Some ramblings on httpd config
On Wed, Jun 3, 2009 at 10:55 PM, Niklas Edmundsson wrote:
> On Wed, 3 Jun 2009, Jorge Schrauwen wrote:
>
>> I know I'm playing with fire now but...
>>
>> XML based config could solve a few of the problems, XML can also be
>> validated.
>>
>> I have to admit lua would be more flexible but I think most server
>> admins have atleast come into contact with XML... while not
>> necessarily the case with lua.
>
> Fire indeed.
>
> I've never seen lua except for Brians examples just now, and lua seems
> usable. XML is just as horrible as our current config scheme and wouldn't
> add much IMHO.
>
well I have to admit XML == fixing a few problems and probably adding lots more.
The example Bertrand Mansion posted does look acceptable to me and
like Rich I could probably live with it quite easly. But also looking
at some other examples I do fear for the madness that will ensure in
users@ and irc.
> I could add more fire to this, just to stir things up a bit:
>
> Those who can't grasp lua probably couldn't grasp our current config scheme
> either. I reckon those would be better served with a shiny web-based
> pointy-clicky config interface, and those people probably couldn't bother
> less what was happening under the covers...
>
True, I haven't looked much a lua before and it does seems acceptable.
I never thought of current method of being difficult to understand.
Then again I am a programmer and been using apache since it's early
1.3 days so most of my troubles in the past are probably covered under
a think layer of dust.
But I don't see how good documentation and some very well thought out
examples could not fix this for lua.
But also try to remember a lot of users@ and IRC PITA's are because
different distro (*cough*debian) ship horribly modified configs to
make it easier for the users.
I fear that if we make a bad choose now, we will see more of these
horrors in the near future.
That being said that me talking and the "user who wants a simple web
server"/"crazy person who tries to help people do that", the server
admin/developer in me screams yes yes yes! bye bye ugly mod_perl
driven config. (Well if we have DBD support at least :p)
> /Nikke
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | ni...@acc.umu.se
> ---
> Acetone = What you do in exercise class...
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
Re: Some ramblings on httpd config
Has anyone looked at VCL that varnish uses? That and some playing with lighttpd's mod_magnet is what rekindled my interest: http://varnish.projects.linpro.no/wiki/Introduction http://varnish.projects.linpro.no/wiki/VCLExamples -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
On Wed, 3 Jun 2009, Jorge Schrauwen wrote:
I know I'm playing with fire now but...
XML based config could solve a few of the problems, XML can also be validated.
I have to admit lua would be more flexible but I think most server
admins have atleast come into contact with XML... while not
necessarily the case with lua.
Fire indeed.
I've never seen lua except for Brians examples just now, and lua seems
usable. XML is just as horrible as our current config scheme and
wouldn't add much IMHO.
I could add more fire to this, just to stir things up a bit:
Those who can't grasp lua probably couldn't grasp our current config
scheme either. I reckon those would be better served with a shiny
web-based pointy-clicky config interface, and those people probably
couldn't bother less what was happening under the covers...
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | ni...@acc.umu.se
---
Acetone = What you do in exercise class...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Some ramblings on httpd config
On Jun 3, 2009, at 16:35, Bertrand Mansion wrote:
Lua can look like this :
DocumentRoot = "/htdocs"
ServerName = "www.example.com"
VirtualHosts = {
"www.example.com" = { DocumentRoot = "/example.com/htdocs" }
}
I'm sure that, given time, I can be persuaded that this is a good thing.
This configuration snippet is certainly compelling. I can see that it
solves real-world problems we actually have, and that it can eliminate
the need for much of mod_rewrite.
Then I look at examples like the one Paul posted on his blog a while
back (http://journal.paul.querna.org/articles/2008/12/23/mod_lua-in-apache-trunk/
) and imagine the furor on us...@.
--
Whatever you do will be insignificant, but it is very important that
you do it.
Mahatma Ghandi
Re: Some ramblings on httpd config
Well lets summerize:
We seem to agree some sort of change to the configuration system is needed?
We don't all seem to be it should be a program like language like lua.
Httpd devs seem to like lua so it has the highest chance of being implemented.
But I think I'll speak for most people helping in users@ and #httpd
that whatever is chose or changed should be documented and also be
somewhat idiot proof?
I've also noticed this sort of discussion has appeared a few times in the past.
Maybe it's also time to actually do something with this discussion
instead of letting it slowly fade?
~Jorge
On Wed, Jun 3, 2009 at 10:35 PM, Bertrand Mansion wrote:
> On Wed, Jun 3, 2009 at 9:47 PM, Jorge Schrauwen
> wrote:
>> On Wed, Jun 3, 2009 at 9:07 PM, Akins, Brian wrote:
>>> On 6/3/09 2:45 PM, "Jorge Schrauwen" wrote:
>>>
I have to admit lua would be more flexible but I think most server
admins have atleast come into contact with XML... while not
necessarily the case with lua.
>>>
>>> XML with conditionals. Please, make it stop...
>>>
>>> I think we are going to have to choose one way (the current way, lua,
>>> something else) and just go with it.
>>>
>>> Nice thing about lua is that the configuration is the runtime "script."
>>> There is no external and internal representation of things. (Well, not
>>> exactly, but close...). Lua is fast enough to just run every request - most
>>> of the "hard" stuff is still in C.
>>>
>>
>> I think going with a language "X" based config system will just give
>> us more horrible questions and make it even harder to trouble shoot
>> things like request X works but request Y doesn't.
>>
>> You might as well provide a building block method and the config c
>> based, will scare off the more casual users just like lua and only
>> allow the oncs who know what they are doing write a decent
>> configuration. (ok that last one is maybe a bit over exaggerated but
>> going pure program language based is a very big learn before usage
>> curve)
>
> Lua is already used exclusively as a configuration language in many
> different softwares.
> It was actually first designed to be a configuration language and it
> was very successful in this area.
>
> "...To make a long story short, yes, we did develop Lua to solve a
> particular problem. Although we developed Lua in an academic
> institution, Lua was never an "academic language", that is, a language
> to write papers about. We needed an easy-to-use configuration
> language, and the only configuration language available at that time
> (1993) was Tcl. Our users did not consider Tcl an easy-to-use
> language. So we created our own configuration language..."
> -- http://www.computerworld.com.au/article/260022/-z_programming_languages_lua
>
>
> Lua can look like this :
>
> DocumentRoot = "/htdocs"
> ServerName = "www.example.com"
> VirtualHosts = {
> "www.example.com" = { DocumentRoot = "/example.com/htdocs" }
> }
>
> It doesn't have to look like code. If you don't want to learn
> programming, you don't have to because Lua code can look like a
> configuration. I think that the current Apache conf style could be
> easily converted into Lua syntax without having to rely on anything
> too fancy for non-programmers.
>
> But if you need power, then Lua probably offers the cleanest and
> fastest available in scripting languages. So you can get the best of
> both worlds :)
>
>
> --
> Bertrand Mansion
> Mamasam
>
Re: Some ramblings on httpd config
On Wed, Jun 3, 2009 at 9:47 PM, Jorge Schrauwen
wrote:
> On Wed, Jun 3, 2009 at 9:07 PM, Akins, Brian wrote:
>> On 6/3/09 2:45 PM, "Jorge Schrauwen" wrote:
>>
>>> I have to admit lua would be more flexible but I think most server
>>> admins have atleast come into contact with XML... while not
>>> necessarily the case with lua.
>>
>> XML with conditionals. Please, make it stop...
>>
>> I think we are going to have to choose one way (the current way, lua,
>> something else) and just go with it.
>>
>> Nice thing about lua is that the configuration is the runtime "script."
>> There is no external and internal representation of things. (Well, not
>> exactly, but close...). Lua is fast enough to just run every request - most
>> of the "hard" stuff is still in C.
>>
>
> I think going with a language "X" based config system will just give
> us more horrible questions and make it even harder to trouble shoot
> things like request X works but request Y doesn't.
>
> You might as well provide a building block method and the config c
> based, will scare off the more casual users just like lua and only
> allow the oncs who know what they are doing write a decent
> configuration. (ok that last one is maybe a bit over exaggerated but
> going pure program language based is a very big learn before usage
> curve)
Lua is already used exclusively as a configuration language in many
different softwares.
It was actually first designed to be a configuration language and it
was very successful in this area.
"...To make a long story short, yes, we did develop Lua to solve a
particular problem. Although we developed Lua in an academic
institution, Lua was never an "academic language", that is, a language
to write papers about. We needed an easy-to-use configuration
language, and the only configuration language available at that time
(1993) was Tcl. Our users did not consider Tcl an easy-to-use
language. So we created our own configuration language..."
-- http://www.computerworld.com.au/article/260022/-z_programming_languages_lua
Lua can look like this :
DocumentRoot = "/htdocs"
ServerName = "www.example.com"
VirtualHosts = {
"www.example.com" = { DocumentRoot = "/example.com/htdocs" }
}
It doesn't have to look like code. If you don't want to learn
programming, you don't have to because Lua code can look like a
configuration. I think that the current Apache conf style could be
easily converted into Lua syntax without having to rely on anything
too fancy for non-programmers.
But if you need power, then Lua probably offers the cleanest and
fastest available in scripting languages. So you can get the best of
both worlds :)
--
Bertrand Mansion
Mamasam
Re: Some ramblings on httpd config
On Jun 3, 2009, at 14:09, Joachim Zobel wrote: Am Mittwoch, den 03.06.2009, 11:08 -0400 schrieb Akins, Brian: It would be interesting if we ditched the current configuration system and just used lua. This does IMHO not address any of the problems users usually have and that are mainly due to a lack of validation. See http://people.apache.org/~rbowen/presentations/apacheconEU2005/hate_apache.pdf for what I consider a good description of the current problems. That presentation was at least somewhat tongue-in-cheek, but I like to flatter myself that it spurred some real changes, and some of the stuff mentioned in there has since been fixed. Having said that, I'm torn on this mod_lua thing. Yes, obviously, it would improve the flexibility of the configuration, but, having spent 10+ years doing end-user support on the mailing list and on IRC, I can tell you that our users are not ready to have to learn a programming language in order to configure their virtual hosts. We would see a mass exodus of our user base, or, more probably, a complete refusal to move off of 2.2. This would be a huge shame, with so many awesome new things just about to see the light of day. On the other hand, our current vhost configuration syntax makes me want to kick puppies, and any solution that makes mod_rewrite unnecessary has my strong support. The directive, along with better documentation, would solve 50% of what people use mod_rewrite for. A less painful way to configure dynamic virtual hosts would solve another 15%. And a healthy dose of education about all the gross misconceptions called "SEO" would solve the rest. Yes, we need some kind of macro thingy in the configuration. And while I think that most of us reading this email thread can handle that thingy being Lua, I honestly don't believe that the folks over on the users@ list can, unless it's something that can be embedded into existing configurations, rather than being the entirety of the configuration. -- Happiness isn't something you experience; it's something you remember. Oscar Levant
Re: Some ramblings on httpd config
On Wed, Jun 3, 2009 at 9:07 PM, Akins, Brian wrote: > On 6/3/09 2:45 PM, "Jorge Schrauwen" wrote: > >> I have to admit lua would be more flexible but I think most server >> admins have atleast come into contact with XML... while not >> necessarily the case with lua. > > XML with conditionals. Please, make it stop... > > I think we are going to have to choose one way (the current way, lua, > something else) and just go with it. > > Nice thing about lua is that the configuration is the runtime "script." > There is no external and internal representation of things. (Well, not > exactly, but close...). Lua is fast enough to just run every request - most > of the "hard" stuff is still in C. > I think going with a language "X" based config system will just give us more horrible questions and make it even harder to trouble shoot things like request X works but request Y doesn't. You might as well provide a building block method and the config c based, will scare off the more casual users just like lua and only allow the oncs who know what they are doing write a decent configuration. (ok that last one is maybe a bit over exaggerated but going pure program language based is a very big learn before usage curve) Jorge > Mod_rewrite goes away, which is a good thing :) > > -- > Brian Akins > Chief Operations Engineer > Turner Digital Media Technologies > >
Re: Some ramblings on httpd config
On 6/3/09 2:45 PM, "Jorge Schrauwen" wrote: > I have to admit lua would be more flexible but I think most server > admins have atleast come into contact with XML... while not > necessarily the case with lua. XML with conditionals. Please, make it stop... I think we are going to have to choose one way (the current way, lua, something else) and just go with it. Nice thing about lua is that the configuration is the runtime "script." There is no external and internal representation of things. (Well, not exactly, but close...). Lua is fast enough to just run every request - most of the "hard" stuff is still in C. Mod_rewrite goes away, which is a good thing :) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
I know I'm playing with fire now but... XML based config could solve a few of the problems, XML can also be validated. I have to admit lua would be more flexible but I think most server admins have atleast come into contact with XML... while not necessarily the case with lua. of course a sort of some lua config stuff would be possible to if httpd would export some binding glue module for example lua,c,perl,... could be provided so complex configurations can potentially be done in a language the admin is familiar with. puts down the oil and matches and waits for the blaze to start. ~Jorge On Wed, Jun 3, 2009 at 8:39 PM, Akins, Brian wrote: > On 6/3/09 2:09 PM, "Joachim Zobel" wrote: > >> This does IMHO not address any of the problems users usually have and >> that are mainly due to a lack of validation. > > First of all, I don't really care about "normal" users, to be honest. Admit > it, I'm not the only one. However, I do know that we can't just break > everything for them. > >> >> See >> http://people.apache.org/~rbowen/presentations/apacheconEU2005/hate_apache.pdf >> for what I consider a good description of the current problems. > > It solves most of the "Missing" page, I think. Also, if the lua doesn't > compile, it's not a valid config. A few of the other points are addressed > by using lua with some "helper" libraries. > > We could ease into this by having modules provide some lua glue for use in > the lua handlers (proxy and cache in particular). > > > > -- > Brian Akins > Chief Operations Engineer > Turner Digital Media Technologies > >
Re: Some ramblings on httpd config
On 6/3/09 2:09 PM, "Joachim Zobel" wrote: > This does IMHO not address any of the problems users usually have and > that are mainly due to a lack of validation. First of all, I don't really care about "normal" users, to be honest. Admit it, I'm not the only one. However, I do know that we can't just break everything for them. > > See > http://people.apache.org/~rbowen/presentations/apacheconEU2005/hate_apache.pdf > for what I consider a good description of the current problems. It solves most of the "Missing" page, I think. Also, if the lua doesn't compile, it's not a valid config. A few of the other points are addressed by using lua with some "helper" libraries. We could ease into this by having modules provide some lua glue for use in the lua handlers (proxy and cache in particular). -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Some ramblings on httpd config
Am Mittwoch, den 03.06.2009, 11:08 -0400 schrieb Akins, Brian: > It would be interesting if we ditched the current configuration > system and just used lua. This does IMHO not address any of the problems users usually have and that are mainly due to a lack of validation. See http://people.apache.org/~rbowen/presentations/apacheconEU2005/hate_apache.pdf for what I consider a good description of the current problems. Sincerely, Joachim
