httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject RE: Configuration modules...
Date Sun, 09 Apr 2000 00:51:16 GMT
On Sat, 8 Apr 2000, William A. Rowe, Jr. wrote:
> Greg Stein wrote:
> > First things first. The plan calls for the data structures first, APIs
> > second. We need to figure out what kinds of operations will
> > be performed
> > against it. Building data structures does not preclude APIs.
> 
> No objection.  My thoughts in a nutshell are;
> 
> Create an api and extensions to the module structure to let modules pass
> back their configuration back to the config engine.  This would allow
> recursion to whatever levels are necessary.  No duplication of the config is
> required, and modules can serialize their own info.  i.e.

This would require more effort by the module developers. Allowing Apache
to retain the configuration provides a number of benefits, and it would be
possible (in the future) for the modules to refer to the retained config
data (rather than storing in their config structures).

IMO, it is better to have a standardized, central config structure rather
than requiring all modules to deal with mapping their internal config to a
standardized form.

> (today...)
> 
> {"DoSomething", add_dir_info, NULL,
>      ACCESS_CONF | OR_OPTIONS, TAKE1,
>      "something that will be done"},
> 
> (tommorow...)
> 
> {"DoSomething", add_dir_info, format_dir_info, NULL,
>      ACCESS_CONF | OR_OPTIONS, TAKE1,
>      "something that will be done"},
> 
> where format_dir_info is a module specific that is passed the config write
> callback (of the config engine is writing the config), and passes the
> formatted config to the callback.  It could write back defaulted config args
> to clarify what the module believes it was told to do :~)

Again: creating functions to do this mapping raises the bar for module
developers. I'd like to see it quite low.

Another point: the command records will probably shrink in size. While we
haven't fully specified this, and it is independent of the 9-step config
development Ryan listed, we believe a good approach is to use a big XML
blob for specifying information about the directives and the module. For
example, your directive spec could look like:

<module name="my_module">
  <directive name="DoSomething">
    <argformat>TAKE1</argformat>
    <placement>ACCESS_CONF</placement>
    <placement>OR_OPTIONS</placement>
    <desc>something that will be done</desc>
  </directive>
</module>

Consider the above as the barest example. There are numerous issues with
that particular XML fragment (things it doesn't cover, better ways to
signal flags, etc). However, it provides an example of one path to take.

Note that module-level information can be provided, too:

<module name="mod_dav">
  <server-token>DAV</server-token>
  <version>0.9.16</version>
  <thread-safe/>
  <directives-replaceable/>
</module>

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


Mime
View raw message