httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Proposal: new config API
Date Mon, 14 Jun 1999 08:30:25 GMT
Manoj Kasichainula wrote:
> 
> On Sat, Jun 12, 1999 at 01:05:14AM -0700, Cliff Skolnick wrote:
> > I would suggest that the config API have a call to check if any config info
> > has changed, or possibly register a callback.  A dynamic config API with a
> > standard way of change notification makes caching config info for
> > performance easier.  This is a good addition to apache IMHO.
> 
> This'll be quite useful for mostly static configs. It won't be useful
> for those sites using lots of dynamic DAV configuration. We could
> allow partitioning the config directive space, and have separate flags
> for each partition. Hmmm...

I'm not sure what you mean here. By dynamic do you mean
changing-frequently, or do you mean not-defined-in-a-config-file? Also,
I'm not sure what you mean by flags/partition. But of course... I'm sure
it all makes sense in your head, no need to go thru all the details as
long as it will work :-)

> Maybe the config module can also return integers for each directive
> registered, presumably hash indices. Then, every config lookup
> wouldn't require a strncmp.

This is the "atom" or "symbol" idea that has kicked around periodically.
It came up in reference to Ralf's EAPI patches with the "hook" stuff or
whatever. If there was a generic mechanism in Apache to register a
symbol and get an integer identifier, then we'd really be golden (for a
lot of things).

>...
> So, are these things worth the effort and complexity:
> 
> - partitions with independant change notification
> - hashed config directives
> - Supporting XML node attributes (I forget the actual term that the
>   XML geeks use) as in <blah tree="deciduous" food="tasty">
> - Supporting limiting what scopes directives can be used in.

XML Attributes really don't need to be supported. When you stop and
consider it, there is a simple transformation that implies only elements
are needed:

<elem attr="value"/>

becomes

<elem>
  <attr>value</attr>
</elem>

In other words, you can define an XML schema which requires no
attributes. The DAV schema follows this rule/pattern.

Caveat: attributes are used for namespace declarations and specifying
the natural language context. In this sense, you could view them as
"addendums" to the data within the XML document.

Re: partitions: I'm not sure of the axis that you're partitioning on. If
I guess this properly, do you mean that I can place all the DAV
directives in a partition and thereby only receive notification for DAV
directives? If this is the case... then a big yes.

Re: scoping: eww. Shooting from the hip... I might suggest that this is
up to the module to deal with, rather than the config system. For
example, let's say that <Directory> and <Location> are part of the
"core" module. The core module records the context of these and exports
functions that state you're in a context. Another module can use that
function to verify that it is within a Directory context. This same
pattern could be used to create other context-modifying or
context-sensitive directives. The bigger problem is how do you create
and impose a context-modifying directive without cooperation? (do you
need to?) If I'm not mistaken, there are four contexts so far:
Directory, Location, Files, and Limit.
[ of course, if the config system can help out with this pattern, then
coolness... ]

Cheers,
-g

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

Mime
View raw message