httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <>
Subject Re: XML configuration revisited
Date Mon, 11 Oct 1999 21:24:03 GMT
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

View raw message