httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject Re: [PATCH] <IfDefine> sections
Date Sat, 18 Apr 1998 15:18:57 GMT
><IfDefine> Sections

This, one presumes, checks for the presence
of a symbol in a new namespace.  Let me 
call it "*features*" after a similar one
in Common Lisp.

Aside: The <IfModule ..> has it's own namespace
and it would be good to only have one, so 
I'd urge redefining <IfModule ..> in terms of this
new one by having each module push a symbol
into *feature* implicitly.

Of course, <if...> forms are needed to avoid loading
parts of that database for which the current
server lacks the tools to validate - even -
their syntax.

*Features* would be good for all kinds of
bracketing, not just per module.  For example
portions of the configuration file that
implement cool bundles of rewrite.

While <if...> sounds like the configuration file
is moving toward a procedural design I'd
rather see it move toward a database model
with <if...> suggesting a labeling on a
portion of the database.

*Features* might be the right way to bracket
parts of the config. file that are presented
in single dialogs of the imaginary GUI.

The tension between database v.s. procedural
is kind of a classic one.  If we provide users 
with a way to push additional symbol into 
*features* (e.g. <PushFeature EnableCoolRewrites>)
or as we already do allow them to load additional
modules, then the config file is order dependent
(i.e. procedural).

It might be best to require all directives
that modify *features* to reside in a
prolog of the confiuration file.

A database model is better for a GUI Config
file interface.  If the symbols in *features*
had values and the config. file reader did
C preprocessor like rewrites things would get
more complex/interesting.

 - ben hyde

View raw message