You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Pratik Patel <pr...@db.com> on 1999/10/11 14:32:29 UTC
XML configuration revisited
Greetings,
I was looking through the archives for this list when I started reading
about the XML configuration discussion.
Has any work been done on this, and is there an DTD (even a rough one)
that someone has already created? We would like to build a DTD that
incorporates the new Java Servlet API's specification on web
applications (http://java.sun.com/j2ee/dtds/web-app_1_2.dtd) with an
Apache configuration DTD.
Our idea at this point is to build a simple DTD that incorporates both
the Apache config details and the future web.xml DTD. For the time
being, we will edit the XML config by hand and write a simple parser to
spit out httpd.conf and jserv.conf/jserv.properties/servlets.properties.
We would like some feedback and see if anyone else is already working on
this, possibly as part of Jakarta.
cheers
Pratik
--------
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
i believe dtd and to validate or not are good for
some and bad for others. further, i believe it may
be attractive to allow for validation but not
necessarily require it.
from experience, while implementing the web.xml
support in tomcat i found the validation really
nice for when i was changing attributes by hand
and inevitably fat-fingered an entry or two. at
times folks just want to go straight from xml data
to the corresponding object and dtd validation
is in the way.
in short, having the option to validate my not
be a bad thing. tomcat has this flag in the
server.xml for this very reason.
hope this helps,
- james
Ben Laurie wrote:
>
> Greg Stein wrote:
> >
> > Ben Laurie wrote:
> > >...
> > > ...I think that until you think about how to integrate subsystems you
> > > haven't addressed any problems that don't fall into the realm of the
> > > bleedin' obvious(tm). To take a really trivial Apache example, some
> > > modules have some configuration that can appear within <VirtualHost ...>
> > > sections, and some that can't. The XDTD should define this, rigorously.
> > > Somehow. Ideally in a way that everyone thinks is good and is
> > > standardised.
> >
> > "Bleedin' obvious(tm)" -- screw DTDs.
> >
> > The XML parser will check for well-formed-ness. Typos will bite people,
> > but I believe most of the use of XML will be through tools rather than
> > hand-coding (therefore, not falling prey to typos). If we want to
> > support the user-input model, then Apache can supply a post-process
> > check that does a depth-first traversal and compares element/attribute
> > names against lists provided by modules (which will catch the common
> > typo errors, but not structural ones). You could possibly validate a
> > subtree against a DTD (things like VirtualHost would need to be declared
> > "open" so it doesn't barf).
> >
> > Essentially, you are *creating* the problem by demanding the use of a
> > DTD. From experience, I can say that mod_dav is working just fine
> > without the use of a DTD. I see no reason to enforce the use of a DTD on
> > the Apache configuration process -- it causes more problems than it
> > solves.
>
> I'm not demanding a DTD. I'm saying that it should be possible to
> validate the configuration file, without actually firing up Apache. This
> also means that tools should be able to say what is legal where, on the
> fly. A DTD is far too restrictive to do this, as I've said several
> times.
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: XML configuration revisited
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Tue, 12 Oct 1999, Ben Laurie wrote:
> I'm not demanding a DTD. I'm saying that it should be possible to
> validate the configuration file, without actually firing up Apache. This
> also means that tools should be able to say what is legal where, on the
> fly. A DTD is far too restrictive to do this, as I've said several times.
During the past weeks we've been translating just the current apache doc's
into XML in a modular fashion. We found that with a little care you can
easily encode enough information in for example this XML to also validate
the syntax; generate appropriate error replies as well as staying close to
actually being the documentation itself. So in that case you get the best
of both worlds.
Looking at apache today, things where not all that rosey though, simple
things such as 'CacheNegotiatedDocs' which has neither a yes/no but is
simply present or not; is just one of the many, many exceptions to the
simple TAKEONE one would expect on first sight. Not to mention
repeatability semantics today; some directives can be stacked, others
require all to be present in a single line.
Dw
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Stein wrote:
>
> Ben Laurie wrote:
> >...
> > ...I think that until you think about how to integrate subsystems you
> > haven't addressed any problems that don't fall into the realm of the
> > bleedin' obvious(tm). To take a really trivial Apache example, some
> > modules have some configuration that can appear within <VirtualHost ...>
> > sections, and some that can't. The XDTD should define this, rigorously.
> > Somehow. Ideally in a way that everyone thinks is good and is
> > standardised.
>
> "Bleedin' obvious(tm)" -- screw DTDs.
>
> The XML parser will check for well-formed-ness. Typos will bite people,
> but I believe most of the use of XML will be through tools rather than
> hand-coding (therefore, not falling prey to typos). If we want to
> support the user-input model, then Apache can supply a post-process
> check that does a depth-first traversal and compares element/attribute
> names against lists provided by modules (which will catch the common
> typo errors, but not structural ones). You could possibly validate a
> subtree against a DTD (things like VirtualHost would need to be declared
> "open" so it doesn't barf).
>
> Essentially, you are *creating* the problem by demanding the use of a
> DTD. From experience, I can say that mod_dav is working just fine
> without the use of a DTD. I see no reason to enforce the use of a DTD on
> the Apache configuration process -- it causes more problems than it
> solves.
I'm not demanding a DTD. I'm saying that it should be possible to
validate the configuration file, without actually firing up Apache. This
also means that tools should be able to say what is legal where, on the
fly. A DTD is far too restrictive to do this, as I've said several
times.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Stein wrote:
>
> Ben Laurie wrote:
> >...
> > ...I think that until you think about how to integrate subsystems you
> > haven't addressed any problems that don't fall into the realm of the
> > bleedin' obvious(tm). To take a really trivial Apache example, some
> > modules have some configuration that can appear within <VirtualHost ...>
> > sections, and some that can't. The XDTD should define this, rigorously.
> > Somehow. Ideally in a way that everyone thinks is good and is
> > standardised.
>
> "Bleedin' obvious(tm)" -- screw DTDs.
>
> The XML parser will check for well-formed-ness. Typos will bite people,
> but I believe most of the use of XML will be through tools rather than
> hand-coding (therefore, not falling prey to typos). If we want to
> support the user-input model, then Apache can supply a post-process
> check that does a depth-first traversal and compares element/attribute
> names against lists provided by modules (which will catch the common
> typo errors, but not structural ones). You could possibly validate a
> subtree against a DTD (things like VirtualHost would need to be declared
> "open" so it doesn't barf).
>
> Essentially, you are *creating* the problem by demanding the use of a
> DTD. From experience, I can say that mod_dav is working just fine
> without the use of a DTD. I see no reason to enforce the use of a DTD on
> the Apache configuration process -- it causes more problems than it
> solves.
I'm not demanding a DTD. I'm saying that it should be possible to
validate the configuration file, without actually firing up Apache. This
also means that tools should be able to say what is legal where, on the
fly. A DTD is far too restrictive to do this, as I've said several
times.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Greg Stein <gs...@lyra.org>.
Ben Laurie wrote:
>...
> ...I think that until you think about how to integrate subsystems you
> haven't addressed any problems that don't fall into the realm of the
> bleedin' obvious(tm). To take a really trivial Apache example, some
> modules have some configuration that can appear within <VirtualHost ...>
> sections, and some that can't. The XDTD should define this, rigorously.
> Somehow. Ideally in a way that everyone thinks is good and is
> standardised.
"Bleedin' obvious(tm)" -- screw DTDs.
The XML parser will check for well-formed-ness. Typos will bite people,
but I believe most of the use of XML will be through tools rather than
hand-coding (therefore, not falling prey to typos). If we want to
support the user-input model, then Apache can supply a post-process
check that does a depth-first traversal and compares element/attribute
names against lists provided by modules (which will catch the common
typo errors, but not structural ones). You could possibly validate a
subtree against a DTD (things like VirtualHost would need to be declared
"open" so it doesn't barf).
Essentially, you are *creating* the problem by demanding the use of a
DTD. From experience, I can say that mod_dav is working just fine
without the use of a DTD. I see no reason to enforce the use of a DTD on
the Apache configuration process -- it causes more problems than it
solves.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Pierpaolo Fumagalli wrote:
>
> Ben Laurie wrote:
> >
> > Pierpaolo Fumagalli wrote:
> > >
> > > Sorry, but I think these two are contraddicting... How can you have a
> > > DTD if you don't know the elements that are in your XML file? Either you
> > > generate a DTD depending on your Apache configuration (so for whatever
> > > module gets compiled in or loaded as DSO) or you cannot properly
> > > "validate" (in the strict term of validation against a DTD) the source.
> >
> > Exactly. This is the point I'm making (which is why I keep calling it an
> > XDTD).
> >
> Ah... Ok... Understood. So, you're not validating unsing a standard DTD,
> but using a custom validator you designed using a custom document
> declaration file that you called XDTD...
> So your XML is not "VALID". (Let's use the strictness of the terms as
> they are defined in the XML spec, otherwise we'll all get confused!)
"XDTD" is a placeholder for some, hopefully standardised, method of
defining the XML's structure that _also_ deals with the idea that Apache
has plug-in modules. I'm simply trying to figure out what the required
properties of this hypothetical validator are. What I am certainly not
proposing is a custom validator.
Some have suggested that XSchema will fulfill the requirements. I
haven't looked yet, but I will.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Pierpaolo Fumagalli wrote:
>
> Ben Laurie wrote:
> >
> > Pierpaolo Fumagalli wrote:
> > >
> > > Sorry, but I think these two are contraddicting... How can you have a
> > > DTD if you don't know the elements that are in your XML file? Either you
> > > generate a DTD depending on your Apache configuration (so for whatever
> > > module gets compiled in or loaded as DSO) or you cannot properly
> > > "validate" (in the strict term of validation against a DTD) the source.
> >
> > Exactly. This is the point I'm making (which is why I keep calling it an
> > XDTD).
> >
> Ah... Ok... Understood. So, you're not validating unsing a standard DTD,
> but using a custom validator you designed using a custom document
> declaration file that you called XDTD...
> So your XML is not "VALID". (Let's use the strictness of the terms as
> they are defined in the XML spec, otherwise we'll all get confused!)
"XDTD" is a placeholder for some, hopefully standardised, method of
defining the XML's structure that _also_ deals with the idea that Apache
has plug-in modules. I'm simply trying to figure out what the required
properties of this hypothetical validator are. What I am certainly not
proposing is a custom validator.
Some have suggested that XSchema will fulfill the requirements. I
haven't looked yet, but I will.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Ben Laurie wrote:
>
> Pierpaolo Fumagalli wrote:
> >
> > Sorry, but I think these two are contraddicting... How can you have a
> > DTD if you don't know the elements that are in your XML file? Either you
> > generate a DTD depending on your Apache configuration (so for whatever
> > module gets compiled in or loaded as DSO) or you cannot properly
> > "validate" (in the strict term of validation against a DTD) the source.
>
> Exactly. This is the point I'm making (which is why I keep calling it an
> XDTD).
>
Ah... Ok... Understood. So, you're not validating unsing a standard DTD,
but using a custom validator you designed using a custom document
declaration file that you called XDTD...
So your XML is not "VALID". (Let's use the strictness of the terms as
they are defined in the XML spec, otherwise we'll all get confused!)
Pier
--
Pierpaolo Fumagalli - IBM Center for Java Technologies
<ma...@us.ibm.com> <ma...@apache.org>
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Pierpaolo Fumagalli wrote:
>
> Ben Laurie wrote:
> >
> > No, Apache config _is_ validated.
> >
> > [...]
> >
> > Well, that's cool, but I'm not sure I understand the "own DTD" aspect:
> > we require a mix (that is, a module needs to be able to say "these tags
> > are valid within that other modules tag-so-and-so").
> >
> Sorry, but I think these two are contraddicting... How can you have a
> DTD if you don't know the elements that are in your XML file? Either you
> generate a DTD depending on your Apache configuration (so for whatever
> module gets compiled in or loaded as DSO) or you cannot properly
> "validate" (in the strict term of validation against a DTD) the source.
Exactly. This is the point I'm making (which is why I keep calling it an
XDTD).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Pierpaolo Fumagalli wrote:
>
> Ben Laurie wrote:
> >
> > No, Apache config _is_ validated.
> >
> > [...]
> >
> > Well, that's cool, but I'm not sure I understand the "own DTD" aspect:
> > we require a mix (that is, a module needs to be able to say "these tags
> > are valid within that other modules tag-so-and-so").
> >
> Sorry, but I think these two are contraddicting... How can you have a
> DTD if you don't know the elements that are in your XML file? Either you
> generate a DTD depending on your Apache configuration (so for whatever
> module gets compiled in or loaded as DSO) or you cannot properly
> "validate" (in the strict term of validation against a DTD) the source.
Exactly. This is the point I'm making (which is why I keep calling it an
XDTD).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Ben Laurie wrote:
>
> No, Apache config _is_ validated.
>
> [...]
>
> Well, that's cool, but I'm not sure I understand the "own DTD" aspect:
> we require a mix (that is, a module needs to be able to say "these tags
> are valid within that other modules tag-so-and-so").
>
Sorry, but I think these two are contraddicting... How can you have a
DTD if you don't know the elements that are in your XML file? Either you
generate a DTD depending on your Apache configuration (so for whatever
module gets compiled in or loaded as DSO) or you cannot properly
"validate" (in the strict term of validation against a DTD) the source.
Pier
--
Pierpaolo Fumagalli - IBM Center for Java Technologies
<ma...@us.ibm.com> <ma...@apache.org>
======================================================
IBM Notes ID: Pierpaolo Fumagalli/Cupertino/IBM@IBMUS
Telephone: +1 (408) 777-5838 - IBM Tieline #: 240-5838
Re: XML configuration revisited
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Ben Laurie wrote:
>
> No, Apache config _is_ validated.
>
> [...]
>
> Well, that's cool, but I'm not sure I understand the "own DTD" aspect:
> we require a mix (that is, a module needs to be able to say "these tags
> are valid within that other modules tag-so-and-so").
>
Sorry, but I think these two are contraddicting... How can you have a
DTD if you don't know the elements that are in your XML file? Either you
generate a DTD depending on your Apache configuration (so for whatever
module gets compiled in or loaded as DSO) or you cannot properly
"validate" (in the strict term of validation against a DTD) the source.
Pier
--
Pierpaolo Fumagalli - IBM Center for Java Technologies
<ma...@us.ibm.com> <ma...@apache.org>
======================================================
IBM Notes ID: Pierpaolo Fumagalli/Cupertino/IBM@IBMUS
Telephone: +1 (408) 777-5838 - IBM Tieline #: 240-5838
Re: XML configuration revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
> > 1) Do not validate.
> >
> > Let XML be well-formed and let the server understand if the format has a
> > valid meaning. This is what currently happens with both Apache and
> > java.apache projects. Wellformness, is these cases, is ASCII compliance
> > (which we take for granted!)
> >
> > This solution allows you to remove the "contract" inside the DTD and
> > replace it with documentation. Exactly like it's done today. True, part
> > of the XML idea is lost.
>
> No, Apache config _is_ validated.
I was referring to the Apache 1.x.x conf files which are validated
internally with hardcoded logic.
> > 2) Use namespaces.
> >
> > Let every module define it's namespace and it's own DTD. Currently the
> > XML spec doesn't allow this, but the XSchema WG is specifically working
> > to integrate what you defined as "XDTD", thus the ability to have
> > different pars of the document being validated by different DTDs.
> >
> > The IBM XML4J parser (don't know about the C++ version) is currently
> > supporting XSchema for validation, but I don't know its status.
>
> Well, that's cool, but I'm not sure I understand the "own DTD" aspect:
> we require a mix (that is, a module needs to be able to say "these tags
> are valid within that other modules tag-so-and-so").
Hmmmm, I don't want to miss your point here. Could you give me a
xml-conf example?
> > 3) Use pseudo-RDF.
> >
> > Create a meta-configuration language which is what a group of four of us
> > (Daniel Lopez Ridruejo, Eric Proud'Hommaux, Pierpaolo Fumagalli and
> > myself) have been discussing at ApacheCon98.
> >
> > This XML should have information _about_ configurations and drive human
> > interaction programs (either GUI, command line or web based) to create a
> > valid configuration file.
>
> Exactly.
>
> > But this could very well be a superset of the configuration XSchema.
>
> Pointer?
oh, sorry, all XML-related information are found at
http://www.w3.org/XML/ and in particular
http://www.w3.org/TR/NOTE-xml-schema-req (XSchema requirements)
http://www.w3.org/TR/xmlschema-1/ (XSchema structures)
http://www.w3.org/TR/xmlschema-2/ (XSchema datatypes)
you would also like to take a look at the
http://www.w3.org/TR/WD-xml-fragment (XML fragment interchange)
which defines how several xml fragments can be merged in a single
document without loosing its structure (as for XML entities) to allow
XML editors to work on fragments without having access to the whole
source. This might be _very_ interesting for sym-linking other xml-conf
files internally.
> > To conclude: using a single DTD for configuration is too complicated,
> > therefore it's not useful unless machine created.
>
> Not quite sure I see why this rules it out?
Well, a _general_ configuration DTD needs to be very loose on
validation, something like
<parameter name="param-name">value</param>
which doesn't make much sense to validate since param-name and value can
be all you want.
On the other hand if we come up with something like
<server name="www.apache.org" port="80">
<directory uri="/">
...
</directory>
</server>
this is _specifically_ for web servers. And not much useful for other
projects.
So, if you come up with something like this
<conf xmlns="http://xml.apache.org/DTD/conf"
xmlns:httpd="http://www.apache.org/httpd">
<httpd:server>
<httpd:name>www.apache.org</httpd:name>
<httpd:port type="integer" default="80">80</httpd:name>
<httpd:directory httpd:uri="/">
...
</httpd:directory>
<httpd:module xmlns:jserv="http://java.apache.org/jserv/">
<httpd:name type="String">mod_jserv</httpd:name>
<jserv:module jserv:manual="off"
jserv:default-url="ajpv12://localhost:8007">
<jserv:mount jserv:uri="/servlets" jserv:location="/root"/>
</jserv:module>
</httpd:server>
</conf>
with a powerful XSchema, you can validate the namespaces saparately say,
for example, that
<!element module (name)>
is associated with the "http://www.apache.org/httpd" namespace and
<!element module (mount*)>
is associated with the "http://java.apache.org/jserv/" namespace.
> > Since configurations should be human editable, we need a way to separate
> > different validation rules on their contexts. Placing validation rule
> > definition to the project/module developers, and allowing those
> > validation rules to be _merged_ without influencing the "container" DTD.
>
> Some validation is probably too complex to handle in "XDTD" but at
> present Apache doesn't detect those: it just fails to work. The majority
> of interesting cases are grammatical, IMO.
True. On the other hand, XSchema provides better validation logic, for
example, indicating you cannot have a string value in a port=""
attribute which doesn't make sense.
> > I believe the XSchema spec is what we lack to provide such a
> > configuration framework. Thing that would also allow configuration tools
> > to work on every ASF project based on it.
>
> That would be doublepluscool.
:) Yep.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
---------------------------------------------------------------------
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
>
> Ben Laurie wrote:
>
> > Actually, I don't think it was lack of code that stalled the discussion,
> > but an embarassment of options on how to solve the "XDTD problem".
>
> [...]
>
> > ...I think that until you think about how to integrate subsystems you
> > haven't addressed any problems that don't fall into the realm of the
> > bleedin' obvious(tm). To take a really trivial Apache example, some
> > modules have some configuration that can appear within <VirtualHost ...>
> > sections, and some that can't. The XDTD should define this, rigorously.
> > Somehow. Ideally in a way that everyone thinks is good and is
> > standardised.
>
> There are solutions to this problem but require a significant perpective
> change.
>
> 1) Do not validate.
>
> Let XML be well-formed and let the server understand if the format has a
> valid meaning. This is what currently happens with both Apache and
> java.apache projects. Wellformness, is these cases, is ASCII compliance
> (which we take for granted!)
>
> This solution allows you to remove the "contract" inside the DTD and
> replace it with documentation. Exactly like it's done today. True, part
> of the XML idea is lost.
No, Apache config _is_ validated.
> 2) Use namespaces.
>
> Let every module define it's namespace and it's own DTD. Currently the
> XML spec doesn't allow this, but the XSchema WG is specifically working
> to integrate what you defined as "XDTD", thus the ability to have
> different pars of the document being validated by different DTDs.
>
> The IBM XML4J parser (don't know about the C++ version) is currently
> supporting XSchema for validation, but I don't know its status.
Well, that's cool, but I'm not sure I understand the "own DTD" aspect:
we require a mix (that is, a module needs to be able to say "these tags
are valid within that other modules tag-so-and-so").
> 3) Use pseudo-RDF.
>
> Create a meta-configuration language which is what a group of four of us
> (Daniel Lopez Ridruejo, Eric Proud'Hommaux, Pierpaolo Fumagalli and
> myself) have been discussing at ApacheCon98.
>
> This XML should have information _about_ configurations and drive human
> interaction programs (either GUI, command line or web based) to create a
> valid configuration file.
Exactly.
> But this could very well be a superset of the configuration XSchema.
Pointer?
> To conclude: using a single DTD for configuration is too complicated,
> therefore it's not useful unless machine created.
Not quite sure I see why this rules it out?
> Since configurations should be human editable, we need a way to separate
> different validation rules on their contexts. Placing validation rule
> definition to the project/module developers, and allowing those
> validation rules to be _merged_ without influencing the "container" DTD.
Some validation is probably too complex to handle in "XDTD" but at
present Apache doesn't detect those: it just fails to work. The majority
of interesting cases are grammatical, IMO.
> I believe the XSchema spec is what we lack to provide such a
> configuration framework. Thing that would also allow configuration tools
> to work on every ASF project based on it.
That would be doublepluscool.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Stefano Mazzocchi wrote:
>
> Ben Laurie wrote:
>
> > Actually, I don't think it was lack of code that stalled the discussion,
> > but an embarassment of options on how to solve the "XDTD problem".
>
> [...]
>
> > ...I think that until you think about how to integrate subsystems you
> > haven't addressed any problems that don't fall into the realm of the
> > bleedin' obvious(tm). To take a really trivial Apache example, some
> > modules have some configuration that can appear within <VirtualHost ...>
> > sections, and some that can't. The XDTD should define this, rigorously.
> > Somehow. Ideally in a way that everyone thinks is good and is
> > standardised.
>
> There are solutions to this problem but require a significant perpective
> change.
>
> 1) Do not validate.
>
> Let XML be well-formed and let the server understand if the format has a
> valid meaning. This is what currently happens with both Apache and
> java.apache projects. Wellformness, is these cases, is ASCII compliance
> (which we take for granted!)
>
> This solution allows you to remove the "contract" inside the DTD and
> replace it with documentation. Exactly like it's done today. True, part
> of the XML idea is lost.
No, Apache config _is_ validated.
> 2) Use namespaces.
>
> Let every module define it's namespace and it's own DTD. Currently the
> XML spec doesn't allow this, but the XSchema WG is specifically working
> to integrate what you defined as "XDTD", thus the ability to have
> different pars of the document being validated by different DTDs.
>
> The IBM XML4J parser (don't know about the C++ version) is currently
> supporting XSchema for validation, but I don't know its status.
Well, that's cool, but I'm not sure I understand the "own DTD" aspect:
we require a mix (that is, a module needs to be able to say "these tags
are valid within that other modules tag-so-and-so").
> 3) Use pseudo-RDF.
>
> Create a meta-configuration language which is what a group of four of us
> (Daniel Lopez Ridruejo, Eric Proud'Hommaux, Pierpaolo Fumagalli and
> myself) have been discussing at ApacheCon98.
>
> This XML should have information _about_ configurations and drive human
> interaction programs (either GUI, command line or web based) to create a
> valid configuration file.
Exactly.
> But this could very well be a superset of the configuration XSchema.
Pointer?
> To conclude: using a single DTD for configuration is too complicated,
> therefore it's not useful unless machine created.
Not quite sure I see why this rules it out?
> Since configurations should be human editable, we need a way to separate
> different validation rules on their contexts. Placing validation rule
> definition to the project/module developers, and allowing those
> validation rules to be _merged_ without influencing the "container" DTD.
Some validation is probably too complex to handle in "XDTD" but at
present Apache doesn't detect those: it just fails to work. The majority
of interesting cases are grammatical, IMO.
> I believe the XSchema spec is what we lack to provide such a
> configuration framework. Thing that would also allow configuration tools
> to work on every ASF project based on it.
That would be doublepluscool.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
> Actually, I don't think it was lack of code that stalled the discussion,
> but an embarassment of options on how to solve the "XDTD problem".
[...]
> ...I think that until you think about how to integrate subsystems you
> haven't addressed any problems that don't fall into the realm of the
> bleedin' obvious(tm). To take a really trivial Apache example, some
> modules have some configuration that can appear within <VirtualHost ...>
> sections, and some that can't. The XDTD should define this, rigorously.
> Somehow. Ideally in a way that everyone thinks is good and is
> standardised.
There are solutions to this problem but require a significant perpective
change.
1) Do not validate.
Let XML be well-formed and let the server understand if the format has a
valid meaning. This is what currently happens with both Apache and
java.apache projects. Wellformness, is these cases, is ASCII compliance
(which we take for granted!)
This solution allows you to remove the "contract" inside the DTD and
replace it with documentation. Exactly like it's done today. True, part
of the XML idea is lost.
2) Use namespaces.
Let every module define it's namespace and it's own DTD. Currently the
XML spec doesn't allow this, but the XSchema WG is specifically working
to integrate what you defined as "XDTD", thus the ability to have
different pars of the document being validated by different DTDs.
The IBM XML4J parser (don't know about the C++ version) is currently
supporting XSchema for validation, but I don't know its status.
3) Use pseudo-RDF.
Create a meta-configuration language which is what a group of four of us
(Daniel Lopez Ridruejo, Eric Proud'Hommaux, Pierpaolo Fumagalli and
myself) have been discussing at ApacheCon98.
This XML should have information _about_ configurations and drive human
interaction programs (either GUI, command line or web based) to create a
valid configuration file.
But this could very well be a superset of the configuration XSchema.
To conclude: using a single DTD for configuration is too complicated,
therefore it's not useful unless machine created.
Since configurations should be human editable, we need a way to separate
different validation rules on their contexts. Placing validation rule
definition to the project/module developers, and allowing those
validation rules to be _merged_ without influencing the "container" DTD.
I believe the XSchema spec is what we lack to provide such a
configuration framework. Thing that would also allow configuration tools
to work on every ASF project based on it.
Hope this is useful.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
---------------------------------------------------------------------
Re: XML configuration revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
> Actually, I don't think it was lack of code that stalled the discussion,
> but an embarassment of options on how to solve the "XDTD problem".
[...]
> ...I think that until you think about how to integrate subsystems you
> haven't addressed any problems that don't fall into the realm of the
> bleedin' obvious(tm). To take a really trivial Apache example, some
> modules have some configuration that can appear within <VirtualHost ...>
> sections, and some that can't. The XDTD should define this, rigorously.
> Somehow. Ideally in a way that everyone thinks is good and is
> standardised.
There are solutions to this problem but require a significant perpective
change.
1) Do not validate.
Let XML be well-formed and let the server understand if the format has a
valid meaning. This is what currently happens with both Apache and
java.apache projects. Wellformness, is these cases, is ASCII compliance
(which we take for granted!)
This solution allows you to remove the "contract" inside the DTD and
replace it with documentation. Exactly like it's done today. True, part
of the XML idea is lost.
2) Use namespaces.
Let every module define it's namespace and it's own DTD. Currently the
XML spec doesn't allow this, but the XSchema WG is specifically working
to integrate what you defined as "XDTD", thus the ability to have
different pars of the document being validated by different DTDs.
The IBM XML4J parser (don't know about the C++ version) is currently
supporting XSchema for validation, but I don't know its status.
3) Use pseudo-RDF.
Create a meta-configuration language which is what a group of four of us
(Daniel Lopez Ridruejo, Eric Proud'Hommaux, Pierpaolo Fumagalli and
myself) have been discussing at ApacheCon98.
This XML should have information _about_ configurations and drive human
interaction programs (either GUI, command line or web based) to create a
valid configuration file.
But this could very well be a superset of the configuration XSchema.
To conclude: using a single DTD for configuration is too complicated,
therefore it's not useful unless machine created.
Since configurations should be human editable, we need a way to separate
different validation rules on their contexts. Placing validation rule
definition to the project/module developers, and allowing those
validation rules to be _merged_ without influencing the "container" DTD.
I believe the XSchema spec is what we lack to provide such a
configuration framework. Thing that would also allow configuration tools
to work on every ASF project based on it.
Hope this is useful.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
---------------------------------------------------------------------
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
Ben Laurie wrote:
>
> James Todd wrote:
> > > ...I think that until you think about how to integrate subsystems you
> > > haven't addressed any problems that don't fall into the realm of the
> > > bleedin' obvious(tm). To take a really trivial Apache example, some
> > > modules have some configuration that can appear within <VirtualHost ...>
> > > sections, and some that can't. The XDTD should define this, rigorously.
> > > Somehow. Ideally in a way that everyone thinks is good and is
> > > standardised.
> > >
> >
> > this is why i'm suggesting that we consider what it
> > would take to manage a collection of component/subsystem/etc
> > configurations as deemed appropriate by the component
> > vs trying to configuration everything nut and bolt a
> > hosting system is and/or may be comprised of in a manner
> > deemed appropriate by the hosting system.
> >
> > the hosting system need not know or be exposed to the
> > component details but instead provided the bare minimum
> > needed to establish the relationship and delegate the
> > work to the component. the work is in definining the
> > interface amongst the container and the component.
>
> I'm finding that a little difficult to parse, but assuming I've
> understood you, I think I agree. However, I suspect that all you've done
> is restated the problem without getting us any closer to a solution.
>
[i'm about 1.5 days away from a 1-week 10th year
wedding anniversary vacation so i will be the first
to admit that it is quite likely that i am somewhat
less then 100% in tune with this thread :) ]
configuration issues have been around from day one
and typically is an afterthought from a less then
black box perspective. as such, i feel the adoption,
usage and extension of software packages is limited.
i believe aggregating software will necessarily
have to open up and delegate a certain amount of
configuration responsibilities to the comprised
components. this approach is the very catalyst
which launched the industrial age ... and the same
needs to be done for software.
some standards and agreed upon interfaces will
evolve but i don't believe that hosting software
need know or care about a large percentage of
the inner workings of a component module and
vice versa. to require such would severly impact
adoption, extension, pluggability, scalability,
etc on all fronts.
further, i feel organically growing configurable
and autonomous components from the ground up and
with the explicit goal of doing one thing really
well (eg servlet container) is actually quite
doable. with some a perspective, i believe stitching
these components together in new and interesting
ways is also quite viable.
hope this helps,
- james
Re: XML configuration revisited
Posted by Scott Tavares <st...@home.com>.
Don't forget Argo/UML
http://www.ics.uci.edu/pub/arch/uml/ &
http://www.ics.uci.edu/pub/arch/uml/v07/docs/codeorg.html
----- Original Message -----
From: Troy Poppe <tr...@sba.miami.edu>
To: <to...@jakarta.apache.org>
Sent: Monday, October 11, 1999 6:22 PM
Subject: Re: XML configuration revisited
> On Mon, Oct 11, 1999 at 11:58:03PM +0200, Jan-Henrik Haukeland wrote:
> > Ben Laurie <be...@algroup.co.uk> writes:
> >
> > > James Todd wrote:
> > > >
> > > > the hosting system need not know or be exposed to the
> > > > component details but instead provided the bare minimum
> > > > needed to establish the relationship and delegate the
> > > > work to the component. the work is in definining the
> > > > interface amongst the container and the component.
> > >
> > > I'm finding that a little difficult to parse, but assuming I've
> > > understood you, I think I agree. However, I suspect that all you've
done
> > > is restated the problem without getting us any closer to a solution.
> >
> > On the contrary, at least James et.al. did a good architectural stab
> > at getting at one solution
> >
> > (http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg)
> >
> > I do feel that James is right (also) when he said that it was the lack
> > of code that sort of damped down the discussion. It's only possible to
> > discuss the "emperors new clothes" that far. BTW AFAI remember, the
> > discussion went much farther than discussing DTD's which is (and to an
> > extent should be) only a _minor_ thing in this problem domain.
>
> Actually, I was about to say the same thing (thanks Jan). We got to
> the point where we determined that we needed to know more about what
> we were looking at as far as scope in order to determine where to go
> next. (ie. look at the code drop and figure out how things are interally
> structured).
>
> Also, does anyone remember the colloraboration(horribly misspelled ;) )
> tool discussion? Did we ever decide on any particular tool? Together/J
> was mentioned, as was VThought. (I remember hearing that we probably
> had a better chance with Together/J because of the Java aspect). Anyone
> adverse to starting that discussion again? Perhaps a [VOTE] thread
> on this?
>
> - Troy
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
:) much appreciated :)
to be honest, ten years just blows me away.
seems just like yesterday we were married.
time has a way of slipping by and you most
certainly can't take it back. it has been a
very long time since we have had a weeks
worth of time to ourselves.
i'm *very* much looking forward to it.
- james
Thor Heinrichs-Wolpert wrote:
>
> James:
> I thought this might be somewhat appropriate for you to take next week. My
> father past it along to me, and I thought it would be fitting, since you are
> in an Apache project after all *g*
> Thor HW
> ------------
> Apache Blessing
>
> Now you will feel no rain
> for each of you will be shelter for each other
>
> Now you will feel no cold
> for each of you will be warmth for each other
>
> Now there is no more loneliness for you
> for each of you will be companion for the other
>
> Now you are two bodies
> but there is only one life before you
>
> Go now to your dwelling
> to enter into the days of togetherness
>
> May your days be good and long upon this earth
Re: XML configuration revisited
Posted by Thor Heinrichs-Wolpert <th...@Echidna.net>.
James:
I thought this might be somewhat appropriate for you to take next week. My
father past it along to me, and I thought it would be fitting, since you are
in an Apache project after all *g*
Thor HW
------------
Apache Blessing
Now you will feel no rain
for each of you will be shelter for each other
Now you will feel no cold
for each of you will be warmth for each other
Now there is no more loneliness for you
for each of you will be companion for the other
Now you are two bodies
but there is only one life before you
Go now to your dwelling
to enter into the days of togetherness
May your days be good and long upon this earth
RE: XML configuration revisited
Posted by Adam Hill <ah...@users.arco.com>.
It seems many development mailing lists I subscribe to are talking about UML
modeling. (What's that story about 100 monkeys doing something then the
whole tribe starts doing it... :-) )
Some notes about both packages.
ArgoUML (http://www.egroups.com/group/argo-dev)
Pros: Free (as in beer) Open Source, Completely Java, Great high level
drawing library. Has XMI support (in/out). Exports GIF's and JPG's.
Cons: Not all diagrams supported (Sequence is a big one missing), still not
1.0
Doesn't support round trip. Crashes occasionally.
Together/J (www.oi.com)
Pros: The best Java UML modeler out there. Complete diagram support.
Supports patterns and template diagrams. Round trip, doc gen, whole 9 yards.
Cons: Free version doesn't include some diagram types (Sequence and State).
Real version is $$$$.00. Not Open Source
Both tools are all Java and run where there is stable Java and Swing.
Neither require 1.2 currently.
adam...
-----Original Message-----
From: James Todd [mailto:james.todd@eng.sun.com]
<snip>
!sweet! let's rock.
tool wise i believe it was togetherJ and argo. i've
used togetherJ and can live with it but i wouldn't
be adversed to trying something else out.
<snip>
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
Troy Poppe wrote:
>
>
> Also, does anyone remember the colloraboration(horribly misspelled ;) )
> tool discussion? Did we ever decide on any particular tool? Together/J
> was mentioned, as was VThought. (I remember hearing that we probably
> had a better chance with Together/J because of the Java aspect). Anyone
> adverse to starting that discussion again? Perhaps a [VOTE] thread
> on this?
>
> - Troy
>
!sweet! let's rock.
tool wise i believe it was togetherJ and argo. i've
used togetherJ and can live with it but i wouldn't
be adversed to trying something else out.
i love visualThoughts drawing capabilities but i can't
see how it will help much more then a box'o crayons
with respect to object modeling, java design, etc when
compared to togetherJ.
now that the code is available, or soon will be, let's
move this discussion to the next level and i'm still
on board to explain why things where done the way they
where in addition to the more forward thinking discussions
such as where we think we should be with regards to
component software configuration, infrastructure,
dependecies, and the like.
- james [1 day out from taking a week off] todd
Re: XML configuration revisited
Posted by Troy Poppe <tr...@sba.miami.edu>.
On Mon, Oct 11, 1999 at 11:58:03PM +0200, Jan-Henrik Haukeland wrote:
> Ben Laurie <be...@algroup.co.uk> writes:
>
> > James Todd wrote:
> > >
> > > the hosting system need not know or be exposed to the
> > > component details but instead provided the bare minimum
> > > needed to establish the relationship and delegate the
> > > work to the component. the work is in definining the
> > > interface amongst the container and the component.
> >
> > I'm finding that a little difficult to parse, but assuming I've
> > understood you, I think I agree. However, I suspect that all you've done
> > is restated the problem without getting us any closer to a solution.
>
> On the contrary, at least James et.al. did a good architectural stab
> at getting at one solution
>
> (http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg)
>
> I do feel that James is right (also) when he said that it was the lack
> of code that sort of damped down the discussion. It's only possible to
> discuss the "emperors new clothes" that far. BTW AFAI remember, the
> discussion went much farther than discussing DTD's which is (and to an
> extent should be) only a _minor_ thing in this problem domain.
Actually, I was about to say the same thing (thanks Jan). We got to
the point where we determined that we needed to know more about what
we were looking at as far as scope in order to determine where to go
next. (ie. look at the code drop and figure out how things are interally
structured).
Also, does anyone remember the colloraboration(horribly misspelled ;) )
tool discussion? Did we ever decide on any particular tool? Together/J
was mentioned, as was VThought. (I remember hearing that we probably
had a better chance with Together/J because of the Java aspect). Anyone
adverse to starting that discussion again? Perhaps a [VOTE] thread
on this?
- Troy
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
agreed. having an agreed upon dtd before anything else
can be done is very short sighted. i've seen quite a
few projects get in very tight loops on that very topic.
by going xml, validated or not, we at least have a config
format which should be easy to change later on when we
know we have to ... since we don't have to write the parser.
we need an xml dtd to start the juices flowing, hence
my submition of tomcat server.xml (the tags have changed
a bit since we've last spoken but the goal is the same)
as some that works at one level and should be easy enough
to shape into whatever we choose moving forward.
bigger picture, i still believe we should start small
and grow this the smallish and understandable components
perspective vs the top-down container perspective. it
will have to be that way for any fast moving and open
(ie easily embraces new technologies) architecture ... to
do othewise would be a never ending spiral.
i'm still game and have not changed my opinions on this
matter a bit ... but open to ideas.
hope this helps,
- james
Jan-Henrik Haukeland wrote:
>
> Ben Laurie <be...@algroup.co.uk> writes:
>
> > James Todd wrote:
> > >
> > > the hosting system need not know or be exposed to the
> > > component details but instead provided the bare minimum
> > > needed to establish the relationship and delegate the
> > > work to the component. the work is in definining the
> > > interface amongst the container and the component.
> >
> > I'm finding that a little difficult to parse, but assuming I've
> > understood you, I think I agree. However, I suspect that all you've done
> > is restated the problem without getting us any closer to a solution.
>
> On the contrary, at least James et.al. did a good architectural stab
> at getting at one solution
>
> (http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg)
>
> I do feel that James is right (also) when he said that it was the lack
> of code that sort of damped down the discussion. It's only possible to
> discuss the "emperors new clothes" that far. BTW AFAI remember, the
> discussion went much farther than discussing DTD's which is (and to an
> extent should be) only a _minor_ thing in this problem domain.
>
> --
> Jan-Henrik Haukeland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: XML configuration revisited
Posted by Jan-Henrik Haukeland <ha...@tildeslash.com>.
Ben Laurie <be...@algroup.co.uk> writes:
> James Todd wrote:
> >
> > the hosting system need not know or be exposed to the
> > component details but instead provided the bare minimum
> > needed to establish the relationship and delegate the
> > work to the component. the work is in definining the
> > interface amongst the container and the component.
>
> I'm finding that a little difficult to parse, but assuming I've
> understood you, I think I agree. However, I suspect that all you've done
> is restated the problem without getting us any closer to a solution.
On the contrary, at least James et.al. did a good architectural stab
at getting at one solution
(http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg)
I do feel that James is right (also) when he said that it was the lack
of code that sort of damped down the discussion. It's only possible to
discuss the "emperors new clothes" that far. BTW AFAI remember, the
discussion went much farther than discussing DTD's which is (and to an
extent should be) only a _minor_ thing in this problem domain.
--
Jan-Henrik Haukeland
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
Ben Laurie wrote:
>
> James Todd wrote:
> > > ...I think that until you think about how to integrate subsystems you
> > > haven't addressed any problems that don't fall into the realm of the
> > > bleedin' obvious(tm). To take a really trivial Apache example, some
> > > modules have some configuration that can appear within <VirtualHost ...>
> > > sections, and some that can't. The XDTD should define this, rigorously.
> > > Somehow. Ideally in a way that everyone thinks is good and is
> > > standardised.
> > >
> >
> > this is why i'm suggesting that we consider what it
> > would take to manage a collection of component/subsystem/etc
> > configurations as deemed appropriate by the component
> > vs trying to configuration everything nut and bolt a
> > hosting system is and/or may be comprised of in a manner
> > deemed appropriate by the hosting system.
> >
> > the hosting system need not know or be exposed to the
> > component details but instead provided the bare minimum
> > needed to establish the relationship and delegate the
> > work to the component. the work is in definining the
> > interface amongst the container and the component.
>
> I'm finding that a little difficult to parse, but assuming I've
> understood you, I think I agree. However, I suspect that all you've done
> is restated the problem without getting us any closer to a solution.
>
[i'm about 1.5 days away from a 1-week 10th year
wedding anniversary vacation so i will be the first
to admit that it is quite likely that i am somewhat
less then 100% in tune with this thread :) ]
configuration issues have been around from day one
and typically is an afterthought from a less then
black box perspective. as such, i feel the adoption,
usage and extension of software packages is limited.
i believe aggregating software will necessarily
have to open up and delegate a certain amount of
configuration responsibilities to the comprised
components. this approach is the very catalyst
which launched the industrial age ... and the same
needs to be done for software.
some standards and agreed upon interfaces will
evolve but i don't believe that hosting software
need know or care about a large percentage of
the inner workings of a component module and
vice versa. to require such would severly impact
adoption, extension, pluggability, scalability,
etc on all fronts.
further, i feel organically growing configurable
and autonomous components from the ground up and
with the explicit goal of doing one thing really
well (eg servlet container) is actually quite
doable. with some a perspective, i believe stitching
these components together in new and interesting
ways is also quite viable.
hope this helps,
- james
Re: XML configuration revisited
Posted by Jan-Henrik Haukeland <ha...@tildeslash.com>.
Ben Laurie <be...@algroup.co.uk> writes:
> James Todd wrote:
> >
> > the hosting system need not know or be exposed to the
> > component details but instead provided the bare minimum
> > needed to establish the relationship and delegate the
> > work to the component. the work is in definining the
> > interface amongst the container and the component.
>
> I'm finding that a little difficult to parse, but assuming I've
> understood you, I think I agree. However, I suspect that all you've done
> is restated the problem without getting us any closer to a solution.
On the contrary, at least James et.al. did a good architectural stab
at getting at one solution
(http://java.sun.com/people/gonzo/tomcat/ConfigService.jpg)
I do feel that James is right (also) when he said that it was the lack
of code that sort of damped down the discussion. It's only possible to
discuss the "emperors new clothes" that far. BTW AFAI remember, the
discussion went much farther than discussing DTD's which is (and to an
extent should be) only a _minor_ thing in this problem domain.
--
Jan-Henrik Haukeland
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
James Todd wrote:
> > ...I think that until you think about how to integrate subsystems you
> > haven't addressed any problems that don't fall into the realm of the
> > bleedin' obvious(tm). To take a really trivial Apache example, some
> > modules have some configuration that can appear within <VirtualHost ...>
> > sections, and some that can't. The XDTD should define this, rigorously.
> > Somehow. Ideally in a way that everyone thinks is good and is
> > standardised.
> >
>
> this is why i'm suggesting that we consider what it
> would take to manage a collection of component/subsystem/etc
> configurations as deemed appropriate by the component
> vs trying to configuration everything nut and bolt a
> hosting system is and/or may be comprised of in a manner
> deemed appropriate by the hosting system.
>
> the hosting system need not know or be exposed to the
> component details but instead provided the bare minimum
> needed to establish the relationship and delegate the
> work to the component. the work is in definining the
> interface amongst the container and the component.
I'm finding that a little difficult to parse, but assuming I've
understood you, I think I agree. However, I suspect that all you've done
is restated the problem without getting us any closer to a solution.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
James Todd wrote:
> > ...I think that until you think about how to integrate subsystems you
> > haven't addressed any problems that don't fall into the realm of the
> > bleedin' obvious(tm). To take a really trivial Apache example, some
> > modules have some configuration that can appear within <VirtualHost ...>
> > sections, and some that can't. The XDTD should define this, rigorously.
> > Somehow. Ideally in a way that everyone thinks is good and is
> > standardised.
> >
>
> this is why i'm suggesting that we consider what it
> would take to manage a collection of component/subsystem/etc
> configurations as deemed appropriate by the component
> vs trying to configuration everything nut and bolt a
> hosting system is and/or may be comprised of in a manner
> deemed appropriate by the hosting system.
>
> the hosting system need not know or be exposed to the
> component details but instead provided the bare minimum
> needed to establish the relationship and delegate the
> work to the component. the work is in definining the
> interface amongst the container and the component.
I'm finding that a little difficult to parse, but assuming I've
understood you, I think I agree. However, I suspect that all you've done
is restated the problem without getting us any closer to a solution.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
Ben Laurie wrote:
>
> Actually, I don't think it was lack of code that stalled the discussion,
> but an embarassment of options on how to solve the "XDTD problem".
that's not the conclusion i came to ... which is
not to say my conclusion is right :)
>
> > > The major issue I see is that Apache's configuration is extensible, but
> > > DTDs are not (at least, as far as I understand them). So, some kind of
> > > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > > I don't know much about them. However, the fact that they are plural
> > > worries me :-)
> > >
> >
> > i'd start bottom up and grow this organically. further
> > i propose considering the configuration approach used
> > by tomcat as a starting point as 1) it is simple and
> > 2) it is based on xml and java and as such should be
> > impervious of many platform specific concerns.
>
> Well, that's fine and dandy, but...
>
> > now, by saying it is simple i am not implying that
> > it will solve world hunger ... quite the opposite.
> > if we can get subsystem (eg tomcat servlet container)
> > configurations to become real and portable then
> > hosting system configuration concerns becomes at
> > some level just a matter of interacting and instrumenting
> > the various subsystems configuration api.
>
> ...I think that until you think about how to integrate subsystems you
> haven't addressed any problems that don't fall into the realm of the
> bleedin' obvious(tm). To take a really trivial Apache example, some
> modules have some configuration that can appear within <VirtualHost ...>
> sections, and some that can't. The XDTD should define this, rigorously.
> Somehow. Ideally in a way that everyone thinks is good and is
> standardised.
>
this is why i'm suggesting that we consider what it
would take to manage a collection of component/subsystem/etc
configurations as deemed appropriate by the component
vs trying to configuration everything nut and bolt a
hosting system is and/or may be comprised of in a manner
deemed appropriate by the hosting system.
the hosting system need not know or be exposed to the
component details but instead provided the bare minimum
needed to establish the relationship and delegate the
work to the component. the work is in definining the
interface amongst the container and the component.
- james
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
Ben Laurie wrote:
>
> Actually, I don't think it was lack of code that stalled the discussion,
> but an embarassment of options on how to solve the "XDTD problem".
that's not the conclusion i came to ... which is
not to say my conclusion is right :)
>
> > > The major issue I see is that Apache's configuration is extensible, but
> > > DTDs are not (at least, as far as I understand them). So, some kind of
> > > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > > I don't know much about them. However, the fact that they are plural
> > > worries me :-)
> > >
> >
> > i'd start bottom up and grow this organically. further
> > i propose considering the configuration approach used
> > by tomcat as a starting point as 1) it is simple and
> > 2) it is based on xml and java and as such should be
> > impervious of many platform specific concerns.
>
> Well, that's fine and dandy, but...
>
> > now, by saying it is simple i am not implying that
> > it will solve world hunger ... quite the opposite.
> > if we can get subsystem (eg tomcat servlet container)
> > configurations to become real and portable then
> > hosting system configuration concerns becomes at
> > some level just a matter of interacting and instrumenting
> > the various subsystems configuration api.
>
> ...I think that until you think about how to integrate subsystems you
> haven't addressed any problems that don't fall into the realm of the
> bleedin' obvious(tm). To take a really trivial Apache example, some
> modules have some configuration that can appear within <VirtualHost ...>
> sections, and some that can't. The XDTD should define this, rigorously.
> Somehow. Ideally in a way that everyone thinks is good and is
> standardised.
>
this is why i'm suggesting that we consider what it
would take to manage a collection of component/subsystem/etc
configurations as deemed appropriate by the component
vs trying to configuration everything nut and bolt a
hosting system is and/or may be comprised of in a manner
deemed appropriate by the hosting system.
the hosting system need not know or be exposed to the
component details but instead provided the bare minimum
needed to establish the relationship and delegate the
work to the component. the work is in definining the
interface amongst the container and the component.
- james
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
James Todd wrote:
>
> Ben Laurie wrote:
> >
> >
> > It has been discussed on the Tomcat mailing list, but so far without
> > much in the way of conclusions.
>
> some conclusions have been formed ... they may not
> necessarily be universally embraced though. i personally
> have been hell'a busy for the last 2 months getting
> servlet 2.2 and j2ee in harmony and thusly have not
> been able to put time back into the config discussion.
>
> the issues is still very alive in my mind and my
> perspectives have not altered significantly. the
> discussions to date seemed to only go so far without
> code in hand ... which to be quite honet still
> baffles me ... but none the less i believe raising
> the bar on component/subsystem configuration is of
> importance.
Actually, I don't think it was lack of code that stalled the discussion,
but an embarassment of options on how to solve the "XDTD problem".
> > The major issue I see is that Apache's configuration is extensible, but
> > DTDs are not (at least, as far as I understand them). So, some kind of
> > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > I don't know much about them. However, the fact that they are plural
> > worries me :-)
> >
>
> i'd start bottom up and grow this organically. further
> i propose considering the configuration approach used
> by tomcat as a starting point as 1) it is simple and
> 2) it is based on xml and java and as such should be
> impervious of many platform specific concerns.
Well, that's fine and dandy, but...
> now, by saying it is simple i am not implying that
> it will solve world hunger ... quite the opposite.
> if we can get subsystem (eg tomcat servlet container)
> configurations to become real and portable then
> hosting system configuration concerns becomes at
> some level just a matter of interacting and instrumenting
> the various subsystems configuration api.
...I think that until you think about how to integrate subsystems you
haven't addressed any problems that don't fall into the realm of the
bleedin' obvious(tm). To take a really trivial Apache example, some
modules have some configuration that can appear within <VirtualHost ...>
sections, and some that can't. The XDTD should define this, rigorously.
Somehow. Ideally in a way that everyone thinks is good and is
standardised.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
James Todd wrote:
>
> Ben Laurie wrote:
> >
> >
> > It has been discussed on the Tomcat mailing list, but so far without
> > much in the way of conclusions.
>
> some conclusions have been formed ... they may not
> necessarily be universally embraced though. i personally
> have been hell'a busy for the last 2 months getting
> servlet 2.2 and j2ee in harmony and thusly have not
> been able to put time back into the config discussion.
>
> the issues is still very alive in my mind and my
> perspectives have not altered significantly. the
> discussions to date seemed to only go so far without
> code in hand ... which to be quite honet still
> baffles me ... but none the less i believe raising
> the bar on component/subsystem configuration is of
> importance.
Actually, I don't think it was lack of code that stalled the discussion,
but an embarassment of options on how to solve the "XDTD problem".
> > The major issue I see is that Apache's configuration is extensible, but
> > DTDs are not (at least, as far as I understand them). So, some kind of
> > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > I don't know much about them. However, the fact that they are plural
> > worries me :-)
> >
>
> i'd start bottom up and grow this organically. further
> i propose considering the configuration approach used
> by tomcat as a starting point as 1) it is simple and
> 2) it is based on xml and java and as such should be
> impervious of many platform specific concerns.
Well, that's fine and dandy, but...
> now, by saying it is simple i am not implying that
> it will solve world hunger ... quite the opposite.
> if we can get subsystem (eg tomcat servlet container)
> configurations to become real and portable then
> hosting system configuration concerns becomes at
> some level just a matter of interacting and instrumenting
> the various subsystems configuration api.
...I think that until you think about how to integrate subsystems you
haven't addressed any problems that don't fall into the realm of the
bleedin' obvious(tm). To take a really trivial Apache example, some
modules have some configuration that can appear within <VirtualHost ...>
sections, and some that can't. The XDTD should define this, rigorously.
Somehow. Ideally in a way that everyone thinks is good and is
standardised.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
Ben Laurie wrote:
>
>
> It has been discussed on the Tomcat mailing list, but so far without
> much in the way of conclusions.
some conclusions have been formed ... they may not
necessarily be universally embraced though. i personally
have been hell'a busy for the last 2 months getting
servlet 2.2 and j2ee in harmony and thusly have not
been able to put time back into the config discussion.
the issues is still very alive in my mind and my
perspectives have not altered significantly. the
discussions to date seemed to only go so far without
code in hand ... which to be quite honet still
baffles me ... but none the less i believe raising
the bar on component/subsystem configuration is of
importance.
>
> The major issue I see is that Apache's configuration is extensible, but
> DTDs are not (at least, as far as I understand them). So, some kind of
> XDTD (to coin an acronym) is needed. I believe such things do exist, but
> I don't know much about them. However, the fact that they are plural
> worries me :-)
>
i'd start bottom up and grow this organically. further
i propose considering the configuration approach used
by tomcat as a starting point as 1) it is simple and
2) it is based on xml and java and as such should be
impervious of many platform specific concerns.
now, by saying it is simple i am not implying that
it will solve world hunger ... quite the opposite.
if we can get subsystem (eg tomcat servlet container)
configurations to become real and portable then
hosting system configuration concerns becomes at
some level just a matter of interacting and instrumenting
the various subsystems configuration api.
- james
Re: XML configuration revisited
Posted by James Todd <ja...@eng.sun.com>.
Ben Laurie wrote:
>
>
> It has been discussed on the Tomcat mailing list, but so far without
> much in the way of conclusions.
some conclusions have been formed ... they may not
necessarily be universally embraced though. i personally
have been hell'a busy for the last 2 months getting
servlet 2.2 and j2ee in harmony and thusly have not
been able to put time back into the config discussion.
the issues is still very alive in my mind and my
perspectives have not altered significantly. the
discussions to date seemed to only go so far without
code in hand ... which to be quite honet still
baffles me ... but none the less i believe raising
the bar on component/subsystem configuration is of
importance.
>
> The major issue I see is that Apache's configuration is extensible, but
> DTDs are not (at least, as far as I understand them). So, some kind of
> XDTD (to coin an acronym) is needed. I believe such things do exist, but
> I don't know much about them. However, the fact that they are plural
> worries me :-)
>
i'd start bottom up and grow this organically. further
i propose considering the configuration approach used
by tomcat as a starting point as 1) it is simple and
2) it is based on xml and java and as such should be
impervious of many platform specific concerns.
now, by saying it is simple i am not implying that
it will solve world hunger ... quite the opposite.
if we can get subsystem (eg tomcat servlet container)
configurations to become real and portable then
hosting system configuration concerns becomes at
some level just a matter of interacting and instrumenting
the various subsystems configuration api.
- james
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
James Davidson wrote:
>
> > I kinda like the approach but ...
> >
> > a) How do you use it if you aren't writing Java?
>
> Just use DOM --
>
> get rool element (verify it's "project")
> get the target elements
> for each target, get it's children tags
> for each child tag, do something that was associated
> with that name
>
> You should be able to do that much with a C based XML parser
Well, it was the linking to a Java class I was really referring to. I
suppose you could make it CORBA or such-like, but that's starting to get
a bit heavyweight. Worth considering though...
> > b) Where does it tell me about att1/att2 in the example above?
>
> Unfortunatly, that's where my example is Java specific -- I'm using
> reflection to pipe those straight into the class... For example,
>
> <newtask att1="foo" att2="bar"/>
>
> I'd reflect into an instance of the class that is associated with "newtask"
> (in my previous email org.apache.reallycool.TaskClass) and use JavaBeans
> setter methods -- this means that I can use the java.beans.* library to find
> the method for setAtt1(String s) and setAtt2(String s) from that instance
> class without knowing its exact type. I set the attributes, and then, at the
> appropriate time (as it is a build system) I call an exec method that fires
> and uses whatever configuration was reflected into it to do it's job.
>
> I don't know how to do this last part in C as I'm *not* a good C hacker (I
> had a different background that led me into Java...)
Well, there isn't a standardised way to do this in C (but see above:
there is in CORBA, I'm pretty sure - and that would be language
independent).
> The problem of course with this example is that this isn't exactly the same
> way you'd do things for a server configuration file -- but I wanted to make
> sure that people aren't limiting themselves to "XML...must...have...DTD"
I think everyone agrees that the position is CAN'T have DTD!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
James Davidson wrote:
>
> > I kinda like the approach but ...
> >
> > a) How do you use it if you aren't writing Java?
>
> Just use DOM --
>
> get rool element (verify it's "project")
> get the target elements
> for each target, get it's children tags
> for each child tag, do something that was associated
> with that name
>
> You should be able to do that much with a C based XML parser
Well, it was the linking to a Java class I was really referring to. I
suppose you could make it CORBA or such-like, but that's starting to get
a bit heavyweight. Worth considering though...
> > b) Where does it tell me about att1/att2 in the example above?
>
> Unfortunatly, that's where my example is Java specific -- I'm using
> reflection to pipe those straight into the class... For example,
>
> <newtask att1="foo" att2="bar"/>
>
> I'd reflect into an instance of the class that is associated with "newtask"
> (in my previous email org.apache.reallycool.TaskClass) and use JavaBeans
> setter methods -- this means that I can use the java.beans.* library to find
> the method for setAtt1(String s) and setAtt2(String s) from that instance
> class without knowing its exact type. I set the attributes, and then, at the
> appropriate time (as it is a build system) I call an exec method that fires
> and uses whatever configuration was reflected into it to do it's job.
>
> I don't know how to do this last part in C as I'm *not* a good C hacker (I
> had a different background that led me into Java...)
Well, there isn't a standardised way to do this in C (but see above:
there is in CORBA, I'm pretty sure - and that would be language
independent).
> The problem of course with this example is that this isn't exactly the same
> way you'd do things for a server configuration file -- but I wanted to make
> sure that people aren't limiting themselves to "XML...must...have...DTD"
I think everyone agrees that the position is CAN'T have DTD!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by James Davidson <du...@x180.com>.
> I kinda like the approach but ...
>
> a) How do you use it if you aren't writing Java?
Just use DOM --
get rool element (verify it's "project")
get the target elements
for each target, get it's children tags
for each child tag, do something that was associated
with that name
You should be able to do that much with a C based XML parser
> b) Where does it tell me about att1/att2 in the example above?
Unfortunatly, that's where my example is Java specific -- I'm using
reflection to pipe those straight into the class... For example,
<newtask att1="foo" att2="bar"/>
I'd reflect into an instance of the class that is associated with "newtask"
(in my previous email org.apache.reallycool.TaskClass) and use JavaBeans
setter methods -- this means that I can use the java.beans.* library to find
the method for setAtt1(String s) and setAtt2(String s) from that instance
class without knowing its exact type. I set the attributes, and then, at the
appropriate time (as it is a build system) I call an exec method that fires
and uses whatever configuration was reflected into it to do it's job.
I don't know how to do this last part in C as I'm *not* a good C hacker (I
had a different background that led me into Java...)
The problem of course with this example is that this isn't exactly the same
way you'd do things for a server configuration file -- but I wanted to make
sure that people aren't limiting themselves to "XML...must...have...DTD"
.duncan
Re: XML configuration revisited
Posted by James Davidson <du...@x180.com>.
> I kinda like the approach but ...
>
> a) How do you use it if you aren't writing Java?
Just use DOM --
get rool element (verify it's "project")
get the target elements
for each target, get it's children tags
for each child tag, do something that was associated
with that name
You should be able to do that much with a C based XML parser
> b) Where does it tell me about att1/att2 in the example above?
Unfortunatly, that's where my example is Java specific -- I'm using
reflection to pipe those straight into the class... For example,
<newtask att1="foo" att2="bar"/>
I'd reflect into an instance of the class that is associated with "newtask"
(in my previous email org.apache.reallycool.TaskClass) and use JavaBeans
setter methods -- this means that I can use the java.beans.* library to find
the method for setAtt1(String s) and setAtt2(String s) from that instance
class without knowing its exact type. I set the attributes, and then, at the
appropriate time (as it is a build system) I call an exec method that fires
and uses whatever configuration was reflected into it to do it's job.
I don't know how to do this last part in C as I'm *not* a good C hacker (I
had a different background that led me into Java...)
The problem of course with this example is that this isn't exactly the same
way you'd do things for a server configuration file -- but I wanted to make
sure that people aren't limiting themselves to "XML...must...have...DTD"
.duncan
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
James Davidson wrote:
>
> > The major issue I see is that Apache's configuration is extensible, but
> > DTDs are not (at least, as far as I understand them). So, some kind of
> > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > I don't know much about them. However, the fact that they are plural
> > worries me :-)
>
> XML is extensible even if the DTD can be rigid. For example, in Ant (a
> little build tool that we are using over in Tomcat land), the first two
> levels of the config file are set, but the next level down is dynamically
> mapped to wherever it needs to go.. Let me give an example:
>
> The build.xml file is structured like:
>
> <project name="Tomcat">
> <target name="main" depends="foo">
> <[taskname] [taskattribute=value]/>
> </target>
> </project>
>
> The taskname is resolved to a class, and instance of that class is created
> and the attributes of the task are reflected into that class via beans
> setter methods to configure it.
>
> This lets us do the following:
>
> <project name="foo">
> <taskdef name="newtask" class="org.apache.reallycool.TaskClass"/>
> <target name="main">
> <newtask att1="foo" att2="bar"/>
> </target>
> </project>
>
> So at runtime, I've created extensibility on the fly using this. In ant, the
> definition of what the task tags can look like is driven by a set of
> defaults and added to by in xml taskdefs -- in some other application such
> as configuration -- the configuration could be read in a central location
> and only the various components interested in particular parts of the config
> file need ask for what they want.
>
> I'm sure that people who think that everything should have a DTD are going
> to choke over this approach, but it gives Ant amazing on the fly flexibility
> to deal with things, lets people writing the config files use a well defined
> easy to read common syntax, and lets the progam itself use standard XML
> libraries to do business.
I kinda like the approach but ...
a) How do you use it if you aren't writing Java?
b) Where does it tell me about att1/att2 in the example above?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
James Davidson wrote:
>
> > The major issue I see is that Apache's configuration is extensible, but
> > DTDs are not (at least, as far as I understand them). So, some kind of
> > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > I don't know much about them. However, the fact that they are plural
> > worries me :-)
>
> XML is extensible even if the DTD can be rigid. For example, in Ant (a
> little build tool that we are using over in Tomcat land), the first two
> levels of the config file are set, but the next level down is dynamically
> mapped to wherever it needs to go.. Let me give an example:
>
> The build.xml file is structured like:
>
> <project name="Tomcat">
> <target name="main" depends="foo">
> <[taskname] [taskattribute=value]/>
> </target>
> </project>
>
> The taskname is resolved to a class, and instance of that class is created
> and the attributes of the task are reflected into that class via beans
> setter methods to configure it.
>
> This lets us do the following:
>
> <project name="foo">
> <taskdef name="newtask" class="org.apache.reallycool.TaskClass"/>
> <target name="main">
> <newtask att1="foo" att2="bar"/>
> </target>
> </project>
>
> So at runtime, I've created extensibility on the fly using this. In ant, the
> definition of what the task tags can look like is driven by a set of
> defaults and added to by in xml taskdefs -- in some other application such
> as configuration -- the configuration could be read in a central location
> and only the various components interested in particular parts of the config
> file need ask for what they want.
>
> I'm sure that people who think that everything should have a DTD are going
> to choke over this approach, but it gives Ant amazing on the fly flexibility
> to deal with things, lets people writing the config files use a well defined
> easy to read common syntax, and lets the progam itself use standard XML
> libraries to do business.
I kinda like the approach but ...
a) How do you use it if you aren't writing Java?
b) Where does it tell me about att1/att2 in the example above?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by James Davidson <du...@x180.com>.
> The major issue I see is that Apache's configuration is extensible, but
> DTDs are not (at least, as far as I understand them). So, some kind of
> XDTD (to coin an acronym) is needed. I believe such things do exist, but
> I don't know much about them. However, the fact that they are plural
> worries me :-)
XML is extensible even if the DTD can be rigid. For example, in Ant (a
little build tool that we are using over in Tomcat land), the first two
levels of the config file are set, but the next level down is dynamically
mapped to wherever it needs to go.. Let me give an example:
The build.xml file is structured like:
<project name="Tomcat">
<target name="main" depends="foo">
<[taskname] [taskattribute=value]/>
</target>
</project>
The taskname is resolved to a class, and instance of that class is created
and the attributes of the task are reflected into that class via beans
setter methods to configure it.
This lets us do the following:
<project name="foo">
<taskdef name="newtask" class="org.apache.reallycool.TaskClass"/>
<target name="main">
<newtask att1="foo" att2="bar"/>
</target>
</project>
So at runtime, I've created extensibility on the fly using this. In ant, the
definition of what the task tags can look like is driven by a set of
defaults and added to by in xml taskdefs -- in some other application such
as configuration -- the configuration could be read in a central location
and only the various components interested in particular parts of the config
file need ask for what they want.
I'm sure that people who think that everything should have a DTD are going
to choke over this approach, but it gives Ant amazing on the fly flexibility
to deal with things, lets people writing the config files use a well defined
easy to read common syntax, and lets the progam itself use standard XML
libraries to do business.
.duncan
Re: XML configuration revisited
Posted by James Davidson <du...@x180.com>.
> The major issue I see is that Apache's configuration is extensible, but
> DTDs are not (at least, as far as I understand them). So, some kind of
> XDTD (to coin an acronym) is needed. I believe such things do exist, but
> I don't know much about them. However, the fact that they are plural
> worries me :-)
XML is extensible even if the DTD can be rigid. For example, in Ant (a
little build tool that we are using over in Tomcat land), the first two
levels of the config file are set, but the next level down is dynamically
mapped to wherever it needs to go.. Let me give an example:
The build.xml file is structured like:
<project name="Tomcat">
<target name="main" depends="foo">
<[taskname] [taskattribute=value]/>
</target>
</project>
The taskname is resolved to a class, and instance of that class is created
and the attributes of the task are reflected into that class via beans
setter methods to configure it.
This lets us do the following:
<project name="foo">
<taskdef name="newtask" class="org.apache.reallycool.TaskClass"/>
<target name="main">
<newtask att1="foo" att2="bar"/>
</target>
</project>
So at runtime, I've created extensibility on the fly using this. In ant, the
definition of what the task tags can look like is driven by a set of
defaults and added to by in xml taskdefs -- in some other application such
as configuration -- the configuration could be read in a central location
and only the various components interested in particular parts of the config
file need ask for what they want.
I'm sure that people who think that everything should have a DTD are going
to choke over this approach, but it gives Ant amazing on the fly flexibility
to deal with things, lets people writing the config files use a well defined
easy to read common syntax, and lets the progam itself use standard XML
libraries to do business.
.duncan
Re: XML configuration revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
Ben Laurie wrote:
>
> Dirk-Willem van Gulik wrote:
> >
> > On Mon, 11 Oct 1999, Ben Laurie wrote:
> >
> > ...
> > > > Our idea at this point is to build a simple DTD that incorporates both
> > > > the Apache config details and the future web.xml DTD. For the time
> > > > being, we will edit the XML config by hand and write a simple parser to
> > > > spit out httpd.conf and jserv.conf/jserv.properties/servlets.properties.
> > > > We would like some feedback and see if anyone else is already working on
> > > > this, possibly as part of Jakarta.
> > >
> > > It has been discussed on the Tomcat mailing list, but so far without
> > > much in the way of conclusions.
> > >
> > > The major issue I see is that Apache's configuration is extensible, but
> > > DTDs are not (at least, as far as I understand them). So, some kind of
> > > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > > I don't know much about them. However, the fact that they are plural
> > > worries me :-)
> >
> > Well, actually by introducing the DTD you kind of shoot yourself in the
> > foot. If you for a moment assumens that your XML is 'correct' and contains
> > no semantic errors (well formness can be cheched on the fly) then you
> > can dynamically build the correct tree in memory flexible enough and
> > without the need for a DTD.
> >
> > This sort of assumes you have tools to do this. Obviously those tools
> > would like to have DTD's or some XSL or XML like data semantics construct
> > to drive the tool itself; so that you can add, say the configuration of
> > module X, by simply splicing in some DTD like info.. causing the tool to
> > add the right widows, fields and widgets.
> >
> > But to return, IMHO adding, or even mandating a DTD from our side smells
> > a lot like shooting ourselfes in the foot.
>
> At the risk of repeating myself... I don't think we need DTDs but we
> need some way to describe the format of the XML.
Totally, this is _exactly_ what Eric (eric@w3c.org), Daniel Lopez
(comanche author), Pierpaolo Fumagalli and I have been talking about
since ApacheCon98!!!
We call that "meta-configurations", which wrap around configurations and
allow project-independent tools to _know_ what to do with the project
configurations based on that information.
XML validation is then needed only for the meta-configuration file which
is written by the project authors and should be read-only for users.
IMO, configuration validation is pointless since your software has to
validate it anyway it its own personal manner and no DTD or XSchema can
cover all logic faults.
My 0.02 Euros.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
---------------------------------------------------------------------
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Dirk-Willem van Gulik wrote:
>
> On Mon, 11 Oct 1999, Ben Laurie wrote:
>
> ...
> > > Our idea at this point is to build a simple DTD that incorporates both
> > > the Apache config details and the future web.xml DTD. For the time
> > > being, we will edit the XML config by hand and write a simple parser to
> > > spit out httpd.conf and jserv.conf/jserv.properties/servlets.properties.
> > > We would like some feedback and see if anyone else is already working on
> > > this, possibly as part of Jakarta.
> >
> > It has been discussed on the Tomcat mailing list, but so far without
> > much in the way of conclusions.
> >
> > The major issue I see is that Apache's configuration is extensible, but
> > DTDs are not (at least, as far as I understand them). So, some kind of
> > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > I don't know much about them. However, the fact that they are plural
> > worries me :-)
>
> Well, actually by introducing the DTD you kind of shoot yourself in the
> foot. If you for a moment assumens that your XML is 'correct' and contains
> no semantic errors (well formness can be cheched on the fly) then you
> can dynamically build the correct tree in memory flexible enough and
> without the need for a DTD.
>
> This sort of assumes you have tools to do this. Obviously those tools
> would like to have DTD's or some XSL or XML like data semantics construct
> to drive the tool itself; so that you can add, say the configuration of
> module X, by simply splicing in some DTD like info.. causing the tool to
> add the right widows, fields and widgets.
>
> But to return, IMHO adding, or even mandating a DTD from our side smells
> a lot like shooting ourselfes in the foot.
At the risk of repeating myself... I don't think we need DTDs but we
need some way to describe the format of the XML.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Dirk-Willem van Gulik wrote:
>
> On Mon, 11 Oct 1999, Ben Laurie wrote:
>
> ...
> > > Our idea at this point is to build a simple DTD that incorporates both
> > > the Apache config details and the future web.xml DTD. For the time
> > > being, we will edit the XML config by hand and write a simple parser to
> > > spit out httpd.conf and jserv.conf/jserv.properties/servlets.properties.
> > > We would like some feedback and see if anyone else is already working on
> > > this, possibly as part of Jakarta.
> >
> > It has been discussed on the Tomcat mailing list, but so far without
> > much in the way of conclusions.
> >
> > The major issue I see is that Apache's configuration is extensible, but
> > DTDs are not (at least, as far as I understand them). So, some kind of
> > XDTD (to coin an acronym) is needed. I believe such things do exist, but
> > I don't know much about them. However, the fact that they are plural
> > worries me :-)
>
> Well, actually by introducing the DTD you kind of shoot yourself in the
> foot. If you for a moment assumens that your XML is 'correct' and contains
> no semantic errors (well formness can be cheched on the fly) then you
> can dynamically build the correct tree in memory flexible enough and
> without the need for a DTD.
>
> This sort of assumes you have tools to do this. Obviously those tools
> would like to have DTD's or some XSL or XML like data semantics construct
> to drive the tool itself; so that you can add, say the configuration of
> module X, by simply splicing in some DTD like info.. causing the tool to
> add the right widows, fields and widgets.
>
> But to return, IMHO adding, or even mandating a DTD from our side smells
> a lot like shooting ourselfes in the foot.
At the risk of repeating myself... I don't think we need DTDs but we
need some way to describe the format of the XML.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Greg Stein <gs...@lyra.org>.
On Sat, 16 Oct 1999, Dirk-Willem van Gulik wrote:
>...
> Well, actually by introducing the DTD you kind of shoot yourself in the
> foot. If you for a moment assumens that your XML is 'correct' and contains
> no semantic errors (well formness can be cheched on the fly) then you
> can dynamically build the correct tree in memory flexible enough and
> without the need for a DTD.
I do this already in mod_dav -- XML input is parsed by Expat and then
thrown into a *lightweight* in-memory structure (using Apache pools, of
course :-). mod_dav then operates against the tree to perform the various
operations.
I imagine the same kind of process for configuration. A module could be
passed a (sub)tree of the XML document. The module does a bit of its own
crawling thru the tree to updates its configuration.
[and we could certainly provide key helper funcs, etc]
The XML tree structures that mod_dav uses was proposed as a patch a while
back (check the STATUS file; I believe it is there). I'm going to redo the
patch and integrate it into Apache 2.0 instead of 1.3. This will be part
of the DAV coding work that I'm planning to do for 2.0.
Note: there is an argument that you should avoid the in-memory tree and do
all processing thru callbacks only. The mental model for that becomes very
difficult (unfortunately), so I chose the build/process model for
code/conceptual cleanliness. Any code jockey that is really interested can
revisit the issue :-)
[for request handling, the event model is lighter on resource usage; for
config processing, the build/process is probably best]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: XML configuration revisited
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Mon, 11 Oct 1999, Ben Laurie wrote:
...
> > Our idea at this point is to build a simple DTD that incorporates both
> > the Apache config details and the future web.xml DTD. For the time
> > being, we will edit the XML config by hand and write a simple parser to
> > spit out httpd.conf and jserv.conf/jserv.properties/servlets.properties.
> > We would like some feedback and see if anyone else is already working on
> > this, possibly as part of Jakarta.
>
> It has been discussed on the Tomcat mailing list, but so far without
> much in the way of conclusions.
>
> The major issue I see is that Apache's configuration is extensible, but
> DTDs are not (at least, as far as I understand them). So, some kind of
> XDTD (to coin an acronym) is needed. I believe such things do exist, but
> I don't know much about them. However, the fact that they are plural
> worries me :-)
Well, actually by introducing the DTD you kind of shoot yourself in the
foot. If you for a moment assumens that your XML is 'correct' and contains
no semantic errors (well formness can be cheched on the fly) then you
can dynamically build the correct tree in memory flexible enough and
without the need for a DTD.
This sort of assumes you have tools to do this. Obviously those tools
would like to have DTD's or some XSL or XML like data semantics construct
to drive the tool itself; so that you can add, say the configuration of
module X, by simply splicing in some DTD like info.. causing the tool to
add the right widows, fields and widgets.
But to return, IMHO adding, or even mandating a DTD from our side smells
a lot like shooting ourselfes in the foot.
On the light side; I am nearly done with the translation of all apache
module and core documentation into XML, with added 'value'. In that it is
geared towards semantics and not lay-out. A raw copy is available for the
asking, I hope to post the full, and checked, version later this week.
We found that, whilst writing it, there is a lot we can, and need to do,
to apache config semantics before it can drive such a tool.
But it is a start.
Dw
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Pratik Patel wrote:
>
> Greetings,
>
> I was looking through the archives for this list when I started reading
> about the XML configuration discussion.
> Has any work been done on this, and is there an DTD (even a rough one)
> that someone has already created? We would like to build a DTD that
> incorporates the new Java Servlet API's specification on web
> applications (http://java.sun.com/j2ee/dtds/web-app_1_2.dtd) with an
> Apache configuration DTD.
>
> Our idea at this point is to build a simple DTD that incorporates both
> the Apache config details and the future web.xml DTD. For the time
> being, we will edit the XML config by hand and write a simple parser to
> spit out httpd.conf and jserv.conf/jserv.properties/servlets.properties.
> We would like some feedback and see if anyone else is already working on
> this, possibly as part of Jakarta.
It has been discussed on the Tomcat mailing list, but so far without
much in the way of conclusions.
The major issue I see is that Apache's configuration is extensible, but
DTDs are not (at least, as far as I understand them). So, some kind of
XDTD (to coin an acronym) is needed. I believe such things do exist, but
I don't know much about them. However, the fact that they are plural
worries me :-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: XML configuration revisited
Posted by Ben Laurie <be...@algroup.co.uk>.
Pratik Patel wrote:
>
> Greetings,
>
> I was looking through the archives for this list when I started reading
> about the XML configuration discussion.
> Has any work been done on this, and is there an DTD (even a rough one)
> that someone has already created? We would like to build a DTD that
> incorporates the new Java Servlet API's specification on web
> applications (http://java.sun.com/j2ee/dtds/web-app_1_2.dtd) with an
> Apache configuration DTD.
>
> Our idea at this point is to build a simple DTD that incorporates both
> the Apache config details and the future web.xml DTD. For the time
> being, we will edit the XML config by hand and write a simple parser to
> spit out httpd.conf and jserv.conf/jserv.properties/servlets.properties.
> We would like some feedback and see if anyone else is already working on
> this, possibly as part of Jakarta.
It has been discussed on the Tomcat mailing list, but so far without
much in the way of conclusions.
The major issue I see is that Apache's configuration is extensible, but
DTDs are not (at least, as far as I understand them). So, some kind of
XDTD (to coin an acronym) is needed. I believe such things do exist, but
I don't know much about them. However, the fact that they are plural
worries me :-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi