You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Manoj Kasichainula <ma...@io.com> on 2000/05/09 05:49:19 UTC
Re: vs. external config
On Wed, Apr 26, 2000 at 06:30:15PM -0700, Doug MacEachern wrote:
> sure, but i have not been convinced the new way is better.
Fair enough. Then backward-compatibility isn't the issue.
> i don't see what the problem is with keeping the option open, so why take
> it away?
Well, if support for it doesn't change the config parser in any way
(and Ryan assured me over beer that it doesn't), then I guess it's not
a big deal. I'm basically reacting to the idea that we should actually
add code to support modules like mod_macro, and perhaps mod_perl's
configuration functions, if the work can be done just as well
externally.
<speech length=long>
There are numerous features that all servers that have configuration
files could use, such as being able to:
- include other files
- support macros
- support conditional evaluation
- get configuration from a db
- get configuration from an LDAP directory
- get configuration from ...
- generate configuration in Perl
- generate configuration in Python
- generate configuration in ...
If you have m such features, and n servers, the world has to expend
O(n*m) effort to add these features to every server. Wouldn't it be
nice if these features were included in separate tools, so that they'd
only be implemented O(m) times? You'd also require far less security
auditing and bug fixing, and people writing new servers (or any other
programs for that matter) could spend more time working on their own
specialized code, rather than solving problems that have already been
solved dozens of times in the past. And smaller pieces are easier to
maintain anyway. This is the goal of OO, but pulled out to the
tool level.
This is why I am strongly encouraging as much separation of features
into external commands as is possible without sacrificing genuinely
useful function.
</speech>
Re: mod_macro
Posted by Manoj Kasichainula <ma...@io.com>.
I'm not writing the code these days, so I'm not going to spend much
more time arguing this; if we haven't been able to convince each other
until now, no amount of back-and-forth will resolve this. And the holy
grail of cleanup is Apache 3.0 anyway :).
On Sun, May 14, 2000 at 12:14:58PM -0400, rbb@covalent.net wrote:
> Yes Manoj, you are correct, duplicating function is a bad thing. However,
> we have yet to find a solution that provides as much flexibility as what
> we currently have in 1.3 using external solutions. If you can provide the
> same function in 2.0 as we currently have in 1.3, we are all willing to
> listen. However every comment you have made on this has caused mod_perl
> to either lose functionality, or the mod_perl parser has to be able to not
> only parse perl, but also all of the httpd.conf file.
OK, now that I've had some time to think about it, I think I have a
solution that's less radical than my earlier proposals and covers all
of the cases that Doug described one: the per-request configuration
case. That is essentially dynamic configuration. Dynamic
configuration was out of the scope of the original config modules
design or of my suggestions. If dynamic configuration is the reason
for mod_perl to have a configuration engine, then let loose. Anyway:
If
httpd -f "| /blah/blah/httpdconfig.pl"
is supported, then you can embed Perl anywhere in your
configuration, because rather than wrapping Perl code in an Apache
config file, you can wrap an Apache config file with Perl code.
--- begin ---
#!/usr/bin/perl
my $serverroot = "/usr/local/apache";
print <<EOF
ServerType standalone
ServerRoot $serverroot
<Directory $serverroot/htdocs>
blahblah
</Directory>
EOF
system("cat", "existingconffile");
&name_vhost_section("perl.apache.org", "63.211.145.10");
&name_vhost_section("httpd.apache.org", "63.211.145.10");
# So sue me; I haven't written enough Perl that does subroutines for
# this to be syntactically correct
sub &name_vhost_section {
my ($hostname, $ipaddr) = @_;
print "<VirtualHost $ipaddr>\n";
print "ServerName $hostname\n;
print "etc.";
}
# and so on...
--- end ---
Perl modules (.pm files) can solve the problem of how to share
vars between an Apache module written in Perl and vars in the
configuration; just use the .pm in both. Or a "do" statement would
work; I'm sure that There's More Than One Way To Do It, but I'm not
the Perl uberdude here.
There are no generated files on the hard drive, because now we're
using a pipe to read in the configuration. But the option is still
available for admins to use an intermediate file if they want.
No parsing of Apache configuration is necessary. Any var that is
necessary for use in other parts of configuration should be set as I
set $serverroot above.
Did I miss anything?
> I am not worried about this code fitting into the cache either,
> because this is configuration code. It shouldn't be run often on a
> running server, and if it is slow, that isn't a big hit in the
> scheme of things.
OK, the cache example wasn't a very good one for this case. :) Sorry,
I'm not as good at this as Dean, yet.
My primary goal here is dead simple code everywhere. Whether the
internal config tree structure actually support mod_macro or mod-perl
style configuration is almost secondary to just making it no longer
necessary.
Re: mod_macro
Posted by Manoj Kasichainula <ma...@io.com>.
On Mon, May 15, 2000 at 09:47:46AM +0200, Fabien COELHO wrote:
> > Now we're getting into personal preference.
>
> Sure, but I gave a lot of time and sweat to m4 for this experience and
> preference;-)
I'm not a huge fan of m4 either (though my experience is primarily
from autoconf).
> The "conditional inclusion macros" or even "variables" job need
> assumptions about the lexical structure and grammar of the file processed,
> and they are quite different from one "language" to the other.
How come? I can't think of a reason, as long as you're using a
sufficient language. cpp isn't, m4 seems to be, a Perl script is.
> There is also a question of 'style'. Apache configuration file has a
> low-constraint line-oriented html-looking style, and it is an issue to
> provide tools compatible with this style.
I wouldn't think it would be hard to write a parser that grabbed all
instances of <Macro...> </Macro> and processed the contents.
> 'power' might also be considered. The issue is to match the need, not
> general purpose programming. So consider what are the problems that
> webmasters may have to face when configuring apache, and how to help them
> to handle these. If you use "m4", you have a full powered language at
> hand, which is not really needed for the average configuration file.
Well, when you have "function" calls, conditional execution, and
modularity through seperate files (as Apache + mod_macro has), you're
not that far off from a full-powered language.
> > My point is that Apache doesn't need to support IfDefine.
>
> Something as this one is really needed. It is used for conditionnal module
> loading.
This can be done with #ifdef in cpp or a standard conditional in m4.
> For instance, if you don't want the module which handles external
> filters;-)
You're funny. :)
> Also IfModule is alsoe needed and can only be done internally.
I have this nagging feeling that IfModule is just too dangerous anyway
without much benefit. If you "forget" to load a module, you get
directives which are ignored silently. It's useful as a way to allow
the standard distributed config file not to break, but other that
that, it seems to me that all it can do is hide errors from the
administrator, which isn't a good thing.
This is one of those cases though where I'd imagine there's some
legitimate use out there, but I just can't think of one other than for
making our current system of default config files work.
Re: mod_macro
Posted by Fabien COELHO <co...@cri.ensmp.fr>.
> > cpp: you cannot have multi line macros... so cpp macros are just useless.
>
> #include is there; but I can see that not being optimal.
Moreover there is no arguments to include.
> > m4: the quoting mecanism `' is horrible (from my poor experience).
>
> Now we're getting into personal preference.
Sure, but I gave a lot of time and sweat to m4 for this experience and
preference;-)
> If you don't like existing languages for doing conditional inclusion
> and macros, isn't it better to write an external filter to do this, so
> that all applications can benefit from a unified syntax?
Not necessarily. I don't think that one tool can solve every problem to
every taste. Otherwise everybody would use "m4" and be happy with it.
The "conditional inclusion macros" or even "variables" job need
assumptions about the lexical structure and grammar of the file processed,
and they are quite different from one "language" to the other. Thus it
often needs to be "particular" to the problem at hand. Thos explains why
cpp macros cannot be used for the line-oriented no-escape mecanism apache
configuration, although I'm very happy with these when I program in C.
There is also a question of 'style'. Apache configuration file has a
low-constraint line-oriented html-looking style, and it is an issue to
provide tools compatible with this style.
'power' might also be considered. The issue is to match the need, not
general purpose programming. So consider what are the problems that
webmasters may have to face when configuring apache, and how to help them
to handle these. If you use "m4", you have a full powered language at
hand, which is not really needed for the average configuration file.
> My point is that Apache doesn't need to support IfDefine.
Something as this one is really needed. It is used for conditionnal module
loading. For instance, if you don't want the module which handles external
filters;-) Also IfModule is alsoe needed and can only be done internally.
> Duplicating function that has already been written for us means more
> bugs, more complexity, more code (meaning less chance of fitting into
> cache as Dean always says). This affects everybody.
Macros processing and other configuration file utilities are only used at
startup, and is not likely to be used after that. Thus the pages holding
the code are more likely to stay on disk most of the time.
Sure, it's better to avoid code replication, what can be achieved by
better developper communication, a better documentation in and out of the
source code. Anyway, one must also solve the problems that need to be
solved...
--
Fabien.
Re: mod_macro
Posted by rb...@covalent.net.
> > Well, they are out at the time, and you don't have to use them if there
> > are in some day;-)
>
> Duplicating function that has already been written for us means more
> bugs, more complexity, more code (meaning less chance of fitting into
> cache as Dean always says). This affects everybody.
Yes Manoj, you are correct, duplicating function is a bad thing. However,
we have yet to find a solution that provides as much flexibility as what
we currently have in 1.3 using external solutions. If you can provide the
same function in 2.0 as we currently have in 1.3, we are all willing to
listen. However every comment you have made on this has caused mod_perl
to either lose functionality, or the mod_perl parser has to be able to not
only parse perl, but also all of the httpd.conf file.
Sometimes the only way to do something is to do it yopurself. I am not
worried about this code fitting into the cache either, because this is
configuration code. It shouldn't be run often on a running server, and if
it is slow, that isn't a big hit in the scheme of things.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
mod_macro
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, May 11, 2000 at 09:15:17AM +0200, Fabien COELHO wrote:
> cpp: you cannot have multi line macros... so cpp macros are just useless.
#include is there; but I can see that not being optimal.
> m4: the quoting mecanism `' is horrible (from my poor experience).
Now we're getting into personal preference. There are choices other
than m4 if you don't like its quoting mechanism. Perl is even quite
possible, especially with its <<EOF construct.
If you don't like existing languages for doing conditional inclusion
and macros, isn't it better to write an external filter to do this, so
that all applications can benefit from a unified syntax?
> > #ifdef SPOON
> > ServerRoot /spoon
> > #else
> > ServerRoot /fork
> > #endif
>
> <IfDefine SPOON> is already in, you don't need this;-)
My point is that Apache doesn't need to support IfDefine.
> Well, they are out at the time, and you don't have to use them if there
> are in some day;-)
Duplicating function that has already been written for us means more
bugs, more complexity, more code (meaning less chance of fitting into
cache as Dean always says). This affects everybody.
Re: vs. external config
Posted by Fabien COELHO <co...@cri.ensmp.fr>.
> > Also, the apache API does not provide sufficient hooks for configuration
> > file processing control.
>
> (Using cpp as the example, because I don't know enough m4)
>
> The only thing we need for this is the ability to read configuration
> from a pipe:
>
> httpd -f '| /lib/cpp /usr/local/apache/conf/httpd.conf'
>
> or whatever.
Sure. It looks good as an argument.
However I know about both cpp and m4. They may be quite powerfull, but
they can't do the expected job...
They need assumptions about the lexical or even the syntactic structure of
the file being processed, which are stronger than those actually used in
the httpd.conf format. Thus if you really want to use them, you have to
struggle with these assumptions with escapes of hacks or whatever. The
result is not very convincing, IMHO.
cpp: you cannot have multi line macros... so cpp macros are just useless.
m4: the quoting mecanism `' is horrible (from my poor experience).
> #ifdef SPOON
> ServerRoot /spoon
> #else
> ServerRoot /fork
> #endif
<IfDefine SPOON> is already in, you don't need this;-)
You also have Include, <IfModule ...>
> > On the other hand, I guess that the more standard the better, hence as
> > Apache does manage it's own configuration parsing, I would rather expect
> > it to provide the basic tools (macro, define, conditionnals, ...) needed
> > to improve the management of such files, which is quite important for
> > apache users, especially ISP. The current state is that some of them are
> > in, and some of them are out.
>
> Right. I'd prefer them all to be out. :)
Well, they are out at the time, and you don't have to use them if there
are in some day;-)
--
Fabien Coelho ___ coelho@cri.ensmp.fr ___ http://www.cri.ensmp.fr/~coelho
Re: vs. external config
Posted by Manoj Kasichainula <ma...@io.com>.
On Tue, May 09, 2000 at 11:20:23AM +0200, Fabien COELHO wrote:
> As for mod_macro, an internal support would be better, bacause there is no
> hook in apache to tell that a new configuration processing is started, and
> to attach per-configuration data, thus it relies on a hack to detect new
> configuration processings.
Sorry, I can't parse this.
> Also, the apache API does not provide sufficient hooks for configuration
> file processing control.
(Using cpp as the example, because I don't know enough m4)
The only thing we need for this is the ability to read configuration
from a pipe:
httpd -f '| /lib/cpp /usr/local/apache/conf/httpd.conf'
or whatever.
> EAPI includes one hook to filter lines, which
> was basically added for mod_define, and can basically only be used for
> such a functionnality.
#ifdef SPOON
ServerRoot /spoon
#else
ServerRoot /fork
#endif
> On the other hand, I guess that the more standard the better, hence as
> Apache does manage it's own configuration parsing, I would rather expect
> it to provide the basic tools (macro, define, conditionnals, ...) needed
> to improve the management of such files, which is quite important for
> apache users, especially ISP. The current state is that some of them are
> in, and some of them are out.
Right. I'd prefer them all to be out. :)
Re: vs. external config
Posted by Fabien COELHO <co...@cri.ensmp.fr>.
> > sure, but i have not been convinced the new way is better.
>
> Fair enough. Then backward-compatibility isn't the issue.
>
> > i don't see what the problem is with keeping the option open, so why take
> > it away?
>
> Well, if support for it doesn't change the config parser in any way
> (and Ryan assured me over beer that it doesn't), then I guess it's not
> a big deal. I'm basically reacting to the idea that we should actually
> add code to support modules like mod_macro, and perhaps mod_perl's
> configuration functions, if the work can be done just as well
> externally.
As for mod_macro, an internal support would be better, bacause there is no
hook in apache to tell that a new configuration processing is started, and
to attach per-configuration data, thus it relies on a hack to detect new
configuration processings.
Also, the apache API does not provide sufficient hooks for configuration
file processing control. EAPI includes one hook to filter lines, which
was basically added for mod_define, and can basically only be used for
such a functionnality. This would tend to suggest that other hooks are
needed if they are to be supported externally. However...
On the other hand, I guess that the more standard the better, hence as
Apache does manage it's own configuration parsing, I would rather expect
it to provide the basic tools (macro, define, conditionnals, ...) needed
to improve the management of such files, which is quite important for
apache users, especially ISP. The current state is that some of them are
in, and some of them are out.
If the thing is well defined and useful, the need for extra tools would be
greatly reduced, and particular and special needs can always be addressed
with external modules, as it is now anyway.
--
Fabien Coelho ___ coelho@cri.ensmp.fr ___ http://www.cri.ensmp.fr/~coelho