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