Re: Future of configuration

[Randy Terbush <ra...@zyzzyva.com>]

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

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



> Dean
> 
> On Mon, 18 Aug 1997, Randy Terbush wrote:
> 
> > Since Dean just raised the question in gui-dev about "what are 
> > ya'll up to" I thought I would post back to this list a brief 
> > synopsis of what the 2 or 3 active persons are working on since it 
> > is somewhat relevant to discussions about config file syntax.
> > 
> > Justin Seiferth and Roman Baron have been working on a Java based 
> > configuration frontend that Justin originally showed us some time 
> > back. http://butler.disa.mil/ApacheConfig/
> > 
> > My main feedback to what is going on in this list has been an 
> > attempt to find a common ground protocol that we can give to any 
> > interface developer which would allow any number of text based, 
> > Java, Tcl, etc. interfaces and should provide us some portability 
> > to other platforms like Win32.
> > 
> > SNMP seems to me to be the logical choice here as there has been an 
> > HTTP MIB under development that I think Harrie Hazewinkel has been 
> > involved with. I've not had success reaching Harrie to get his 
> > feedback on SNMP issues. Perhaps Dirk knows what's up with Harrie?
> > 
> > As for how this relates to current discussion about added 
> > directives and other configuration languages, I _personally_ think 
> > that abstracting the configuration language out of the core would 
> > be a good thing. Adding SNMP to manipulate the servers 
> > configuration data directly would offer a rather standard API that 
> > could even be portable to other web servers given that they could 
> > adopt the same public standard. Feedback from Harrie on this issue 
> > would be very helpful.
> > 
> > Given a config API to work with, I personally relish the idea of a 
> > telnet accessed config using similar syntax to that of a cisco 
> > router.
> > 
> > On disk storage formats could then be optioned to:
> > 
> > * SQL database
> > * DB format
> > * current text format
> > * Win32 Registry format (god help us)
> > * etc.
> > 
> > Obviously all 2.0 issues.
> > 
> > In a nutshell. Comments solicited.
> > 
> > -Randy
> > 
> > 
> > 
> >