httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
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 http://yakko.com/dot/ wouldn't affect
http://yakko.com/wakko/. 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).

Right.

> 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 - http://www.io.com/~manojk/
"Anybody who says 'disk is cheap' deserves to be shot." - Linus Torvalds

Mime
View raw message