httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Proposal: new config API
Date Mon, 14 Jun 1999 20:01:00 GMT
On Mon, Jun 14, 1999 at 01:30:25AM -0700, Greg Stein wrote:
> Manoj Kasichainula wrote:
> > 
> > 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?

Should've been clearer. I meant configuration that changes frequently.

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

We divide the space of all possible config directives into partitions.
Maybe we could also devide based on the URI space, so that config
directives for wouldn't affect Then, we can ask the config system to tell us
whether any configuration in a particular partition has changed. That
way, we can separate out the config directives that won't change
frequently from those that will.

What do you think?

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


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

OK, then. Next question. Should nested nodes be supported? :)

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

Yeah, that's what I'm referring to.

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

My thought was that these would actually be part of the config system.
The core and modules would only get to register things that go in
these blocks. When a module asks for the value of a config variable,
it also provides a URI, so that config system can return the correct
value for that URI. I don't know if this will be feasible though.

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

I need to ponder this for a while. :)

Manoj Kasichainula - manojk at io dot com -
"Anybody who says 'disk is cheap' deserves to be shot." - Linus Torvalds

View raw message