www-gui-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: Future of configuration (fwd)
Date Mon, 18 Aug 1997 23:09:50 GMT
(I'm not on gui-dev.)

> ---------- Forwarded message ----------
> Date: Mon, 18 Aug 1997 13:00:46 -0500
> From: Randy Terbush <randy@zyzzyva.com>
> Reply-To: gui-dev@apache.org
> To: gui-dev@apache.org
> Subject: Re: Future of configuration 
> 
> > A month or so ago Doug and I were talking about the functions he needed
> > from the core to implement the perl config funkiness.  I think we agreed
> > that if we could change the configuration code to read from a callback
> > instead of just from a file that he could do everything he needed.  This
> > is actually very easy to implement (even as a stop-gap before SFIO in 2.0) 
> > because all configuration code passes around a pseudo-global cmd_parms. 
> > 
> > It would be trivial to add another two fields to that to put in a callback
> > with arbitrary void *data pointer.  Then only one or two places need to
> > know about the callback.
> > 
> > This is a desirable change for mod_perl because it would mean mod_perl
> > needs access to fewer of the core functions.  It could be used to
> > implement some other config mechanisms ... but I doubt it could be used to
> > do SNMP.  SNMP mgmt seems like a hard thing to integrate into apache. 
> 
> I'll yield to your expertise on this matter, but it seems that an 
> SNMP MIB could be integrated that would manipulate a copy of the 
> current running configuration data. A 'copy run start' would copy 
> that with new optimization calculations into the running config. ??

If you have a command that says "restart now" then yeah it's feasible. 
It's just not feasible to incrementally change the config of a running
server. 

> > With the way config works in present day apache it is possible to do it
> > only at start/restart time.  snmp and telnet interfaces would seem really
> > hard to retrofit... I'm assuming you want to do something while it's live
> > and running.  And some of the optimizations I mumble about (and have
> > implemented already) involve doing pre-calculations at config time to save
> > time in the critical path.  It'd suck to have to redo these calculations
> > (and respawn all the children) with every line entered in a telnet window
> > :)  Or maybe I'm confused by what you want. 
> 
> I picture the config data being read from disk in some format that 
> the server wants to see it in. The configuration interfaces could 
> make sense of that to give a user perspective. This should allow 
> you to store the data in a way that is optimized for the server.

Well parsing is pretty cheap ... even hotwired's 800k config files (don't
ask!  it's legacy, yeah, that's it) are parsed pretty fast. 

So maybe that change to the parser is good enough for your needs then.

Dean


Mime
View raw message