httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: XML config
Date Mon, 17 Jan 2000 22:01:16 GMT
> That wasn't my only problem, but I have to ask: if you can't validate
> it, how can you define it? If you can't define it, how can you expect
> anyone to use it?

The server will validate the config anyway, DTD isn't the only
solution ( the current config is validated well enough and defined
well enough - without any DTD )

> a) Namespaces. I think this is a no-brainer if you are prepared to have
> long names, but is that reasonable?

I think namespaces are good, even if DTD-namespace relation is 
bad, and some parsers might get confused.

> b) Conditions: a vital point, I think, is that some Apache modules deal
> with what configuration is currently applicable, and the rest only worry
> about the current applicable configuration. This is currently handled by
> mucho magic inside Apache, and it'd be nice if it weren't.
> It occurs to me that what I was really trying to get at with my proposal
> was the idea that as each element is processed, it should determine how
> the contained elements are processed (or not) by the module that

In Java and tomcat - it's easy, the "module" is  a java class that
has enough information inside ( i.e. the configurable properties
names and types are known).

In C - an equivalent way is to set properties into a module
 using a "module method", and probably either the module setter 
will validate the content or you can have an additional "method"
to give you introspection info. 

> and it is possible to cache the results, then the <Module...> notation

I was thinking of <Module > as another way to define the module
information - attributes can be "name", "module_so_file", "java_class",
and it may have information about the module properties.

Instead of getting the "validation" data for the module using
introspection ( or callbacks), or DTD - you can use <module>
as a replacement for DTD.


View raw message