httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wilson <and...@aaaaaaaa.demon.co.uk>
Subject Re: Hello.. and why stick with NCSA config format?
Date Thu, 09 Jan 1997 21:41:59 GMT
Hi,

    [i reformatted the mail a little for 80 char lines]

> Jason S. Clary:
>  
>  
> Hello guys...  Brain said I should stop by and make my suggestions
> and ask my questions of you guys.
> 
> I'm currently writing an SSL patch for Apache that is us-legal
> because..  well.. I'm in the US and even though I absolutely love
> SSLeay, I don't want to get stuck with a law suit from RSA.
> 
> Anyways, SSLRef 3.0 is out and my patch is almost done.. (would
> have been done on tuesday but I have been very sick with the flu
> for a bit and I was effectively out of action the last couple days)

[API abstraction to let modules control lower level aspects of
server io... snip]

Sounds like a sensible idea.

> As far as the configuration goes, does anyone here know of a good
> reason to stick with NCSA's config format?  I mean, if there were
> major changes in the core internal configuration of some sort would
> you be opposed to change the config file formats to be easier to
> deal with and be more like what the server is actualy doing?

Following from your own example, why not let a module handle this
also.  Would it be impossible to convert .htaccess and .conf
directives to PERL syntax and use the power of a native mod_perl
module to process these directives?  The point being that you'd
define a mod_parse_config_std.c for how Apache behaves now, and
then a mod_parse_config_perl.c for those of you who wish for Apache
to be easier to configure (of which there must be several...).

Of course the drawback in releasing a server with *only* a new,
incompatible configuration format is obvious.  N hundred thousand
installations that would need to convert their configurations.  A
script to automate this change would be, well, tricky.  Doing it
by hand?

I think that the configuration language's semantics *are* Apache,
in essence, and in the future the desire for a programmatic interface
to configuration will, I'm sure become more prevalent.  Letting
people configure apache in PERL or Java or Tcl (tcl8.0 has a
JIT-bytecode compiler and a first rate api), can only extend the
range of expression possible with this tool.

Abstracting the configuration management aspects of the server, in
order to provide scope for modules that support alternate syntax
would be good.

> I'm just mainly wondering...  I've been using Apache for going on
> 2 years now and adding my own patches and whatnot all this time
> (unfortunately in my previous job as admin of an internet provider
> I never had time to finalize any of my patches for general use..
> they were all very specific and down-and-dirty for what we needed).
> One thing I think desperately needs to be done is to get rid of
> the listener config, and even the main host config.. then just have
> the global configuration stuff for the server itself in httpd.conf
> with directives of this sort:
> 
> HostConfig conf/myfirsthost
> HostConfig conf/mysecondhost
> <Host mythirdhost>
> Port 80 Clear
> Port 443 SSL-Internation
> Port 444 SSL-US
> Port 446 SET
> 
> ...  # all the rest of the normal stuff you'd have for a virtual host
> 
> </Host>
> 
> HostConfig would let you read in more hosts from separate files
> (the files would be just like whatever is inside a <Host> block
> but without the <Host> tags themselves)..  This would greatly
> simplify things for people like myself who administer commercial
> hosting services.
> 
> Second, Port could be made cumulative.. with a port table of some
> sort in the configuration.. the second option would be a IO handler
> name.. as registered by the IO handler module at load time.  The
> table should probably include port number, handler, default handler
> port, and default protocol method (i.e. http, https) We could assume
> Clear if its left off.
> 
> Ok, now you may be saying "Who is this dolt and why is he trying
> to tell us what we should do"... well, I'm "jus zis guy, ya know?"
> (sorry, random HitchHiker's Guide to the Galaxy quote disease)..
> actualy, these are just suggestions from someone who's been using
> Apache and NSCA both for years and who would absolutely LOVE to
> see Apache stay the number 1 web server and eventualy be the fastest
> and best web server available.. and still free, highly extensible
> and customizable.

Rad.

> Anyways, the only reason I'd say change from <Virtualhost> to <Host>
> is because of the gross change in the way configuration is handled..
> it would help to avoid confusion.  Of course we will have to tell
> the people at microsoft to alter their Front Page extensions for
> Apache.. ;)  But even just providing for external definitions of
> virtual hosts would require that.
> 
> I'm not saying you should do any of this.. I just think it would
> be handy for a lot of us.  Since you are about to do a major re-write
> of the core anyways, its best done now.  I'm open to discussion
> about any of this.. please give me any reason you have for why this
> stuff should or shouldn't be done.
> 
> Again, don't get mad.. I don't think what I'm saying is necessarily
> the best way or even at all close.. I just am wondering your opinion
> on it and if you like it I would be very pleased if something
> similar showed up in future versions of Apache..
> 
> Thanks a bunch.
> 
> Jason Clary

I love big words.

Cheers,
Ay.

-- 
Andrew.Wilson@cm.cf.ac.uk http://www.cm.cf.ac.uk/User/Andrew.Wilson/

Mime
View raw message