[Zope] Re: [Zope-dev] Proposed installation changes for review

[Jamie Heilman]

Jeremy Hylton wrote:
> I don't know what work means in this context, but think the ZConfig
> project is thorough.  In my checkout there are 180k of document, 180k of
> unit tests, and 136k of code.  A measure of work that suggests that
> something with 0k of documentation and tests and 136k of code would be
> better makes no sense to me.

How about, "a lot of code/documentation was removed, and a lot of new
code/documentation was added."  Don't get hung up on the exact
numbers, my point was, a lot of work has gone into "simplifying" the
configuration process, but that the bigger picture isn't any clearer
for it.

> I don't see where the UNIX philosophy has anything useful to say about
> configuration, but maybe I'm just a closet unix hater <0.5 wink>.

Small programs that do one thing well, written to work together,
communicating via a universal interface, have the golden property of
being easily replaceable.  With this replaceability comes the ease of
configuration.

> I don't see that configuration gets any easier if you have multiple
> processes.  Even if Zope had N processes, there would still be the same
> amount of stuff to configure.

There is more than one way to ease configuration.  Reducing the
"amount of stuff" is one way, but sometimes, even after you've reduced
till you can't reduce any further, there's still a lot of "stuff."
Another way to ease configuration is to make things modular so its
easier to visualize the flow of data.  When the boundaries of
communication are clearly defined between modules it becomes easier to
understand what part each module plays, and how you can affect the
overall result by changing or re-organizing the individual modules.

> You'd probably still want a single master config file for the whole
> thing, and a tool to check the configuration is valid separate from
> the process that uses the file to configure itself.

Not I.  Large applications with a master config file are to be held
with suspicion.  Their longevity inevitably suffers because they are
difficult to adapt to new situations.

> As I watched everyone working on the ZConfig project, I was
> impressed with how many issues are involved in getting a decent
> configuration system.

Indeed.

> I don't think that break the server into multiple pieces would make
> it easier to configure, and I don't see what requirements could have
> been eliminated to make the project take less work.

Well, when you've got some cycles to burn, give it some more thought.
It may not be as obvious to you if you don't deal with it on a day to
day basis like sysadmins do, but I assure you UNIX owes much of its
longevity to the philosophies upon which it was built.  Adaptability is
a big deal.

-- 
Jamie Heilman                   http://audible.transient.net/~jamie/
"We must be born with an intuition of mortality.  Before we know the words
 for it, before we know there are words, out we come bloodied and squalling
 with the knowledge that for all the compasses in the world, there's only
 one direction, and time is its only measure."		-Rosencrantz