On Mon, 2003-03-10 at 19:51, Jamie Heilman wrote:
> > - Environment variables are no longer used for configuration.
>
> I'll say it one more time.
>
> The roadmap[1] states under the "Simplifying the Zope experience"
> section:
>
> * simple tasks should be simple!
>
> Now, code required to extract a value from the environment:
>
> import os
> try: value = sanitize(os.environ.get("SOMETHING", default))
> except Unsanitary:
> ...cope...
>
> # where 'sanitize' is in reference to any conversion procedures required
> # prior to the use of 'value' by program code
I'm sure you know this, but you are oversimplifying the situation.
There are 41 (known) individual environment variables that control
Zope's runtime configuration. Each use of an environment variable has
its own parsing code, its own error-handling code and the actual code
that does the work (ex: the session envvar parsing stuff in
OFS/Application.py). If we take your example and make the error
handling code "real" and the work code "real" we can estimate that it
will consume about 1k. Multiply the number of bytes it contains with 41
and we can approximate about 41k of ad-hoc envvar handling code in Zope
now. That's a boatload of largely untested and decentralized code, all
of which is doing configuration. There is nothing simple about it. ;-)
> Pretty simple. Enter ZConfig:
> $ du -sk ZConfig
> 374 ZConfig
>
> 374k of work devoted to replacing os.environ.get and its sanitizing
> code, and the result is a XML config file. I'm not saying this all
> for naught, but really, it should give you pause. Just how much have
> you really simplified configuration by doing this?
I couldn't really guess how much code in Zope is devoted to runtime
configuration right now because it's spread over the entire codebase. I
suspect you're right that it's not 374k. But for ZConfig only 116k is
code, the rest is docs and tests: there are neither (to speak of,
discounting the laughable ENVIRONMENT.txt) in the current 2.6/trunk
codebase for configuration.
> Personally I think the problem of Zope's configuration hassles has
> been mis-identified. ZConfig cleans up and centralizes a maze of
> badly strewn out configuration code. It will extend the lifetime of
> the Über-server concept ZServer employs. It does nothing to prevent
> the same mess from happening again, down the road.
Actually, it does. Packages may declare their own config schema type
definitions and they may be included in the context of a larger
configuration schema. This is demonstrated in the Zope schema in the
new-install-branch in lib/python/Zope/Startup/zopeschema.xml:
<schema prefix="Zope.Startup.datatypes"
datatype=".root_config"
handler="root_handler">
<!-- type definitions -->
<import package="zLOG"/>
<import package="ZODB"/>
<import package="ZServer"/>
....
We import the schema type definitions from the zLOG, ZODB, and ZServer
packages here (these are named component.xml in each of these
packages). The zope schema file uses these definitions to compose its
own (type-checked) schema for a config file, and they can be (and will
be) reused for ZEO and ZC's ZRS (Zope Replication Server).
For Zope, ZServer is just another package that happens to define the
schema type definitions for network servers.
> I believe a more
> lasting approach is to seperate the servers into small individual
> programs which only do 1 thing, and do it well. Then you combine
> those servers under a unified mangement framework, connect them
> together by using common communication idioms, the idea being--and
> follow me here, to use small programs combined together to provide a
> larger service. Sound familiar?
I think this is done already. ZConfig is very general and very generic;
you can configure just about anything with it and it has no Zope
dependencies whatsoever. Fred Drake wrote it so it's pretty solid too.
Before dismissing it out of hand, I'd encourage you to try it out.
- C
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
