[Zope3-dev] ZCML alternative

[Jim Fulton]

Shane Hathaway wrote:
> 
> I'm proposing a ZCML alternative that I'd like feedback on before
> wikifying.  But first some background.
> 
> I've been thinking about the difficulty Itamar had recently.  Several
> months ago, he integrated Twisted (an Internet protocol framework) into
> Zope 3 with very little effort.  It was an exciting thing to be able to
> do.  But after we converted the startup procedure to use ZCML, Itamar
> tried again to integrate Twisted and failed, because the startup
> mechanisms were too hard to decipher.  I tried to help, but I couldn't
> wrap my head around what it would take to add a different kind of server
> either.  Itamar blamed ZCML, and I tried to convince him otherwise, but
> now I'm having second thoughts.
> 
> ZCML fulfills an important role.  As the Wiki says,

What page you you refering to?


> it separates
> component configuration from component software.  That's a very
> powerful, important concept.

Yes, this is a given.

> But maybe the separation shouldn't be
> enforced by having a separate language.
> 
> Some specific problems with ZCML:
> 
> - It's hard to find the code that processes a given directive.

Why is that important to the users of ZCML?
 
> - It's hard to tell what a ZCML file depends on without reading every line.

I have no idea what you are saying here. Could you explain what you mean?
 
> - You can't easily use debugging tools, like "print" statements, pdb, or
> the interactive interpreter. 

I assume the "you" you are refering to is the site manager (not
the directive author), right? I think we should make there job easier, 
but it's really unclear to me how they would want to debug a configuration.
I don't see why Python configuration files would make thier job easier.


> We have tracebacks, but they aren't very
> clear.

Yeah, they used to be a lot easier to read. 8/
 
> - We've had to invent syntax to cover things that XML does not address,
> like Python imports and lists.

I don't see that this is much of a problem. In fact, I find the 
dotted names easier to use that Python imports in a alot of ways.
 
> I'd like to suggest that configurations are objects.  Object
> encapsulation gives you separation.  Besides being objects,
> configurations are also components, so they implement an interface. 
> With that in mind, I took the JobBoard ZCML file and rewrote it as a
> Python class.  I liked the results.  I'm sure there are typos.
> 
> The approach provided easy answers to a lot of the ZCML syntax issues.
> register() is the one method required.  Namespaces weren't really
> needed, so I didn't use them.  There are groupings in the ZCML using
> comments, so I turned those into separate methods.  I used Python
> imports instead of ".xxx.".  I used lists.  I avoided using Python
> keywords as argument names through the use of positional arguments.
> 
> Comments?

Here are what I consider some important goals of ZCML:

1. Configure is separate from software

2. The configuration language is used by site managers,
   not developers. Many of them don't know Python. It's
   my guess that more of them understand XML syntax than
   understand Python syntax.

   The simplicity of XML is a big advantage here. Python is
   too expressive. People who know Python will use clever features
   that site managers will never grok.

   The real complexity in any syntax is the semantics, which need to
   be well explained. We need to do a better job of that, but heck, 
   we're working as fast as I can.

3. Site managers need to be able to *override* configuration
   without changing the original configuration source. That
   would be very hard to achiev in Python. In fact, a lot of
   the difficulty in figuring what's going on under the hood
   and debugging zcml arises from the delayed execution
   needed to make this work.

4. It's important for the configuration to be extensible.
   It should be possible to create new directives, and, we're
   finding out, it's important to be able to extend existing
   directives.

I can see a Python based approach satisfying goals 1 and 4, 
but not 2 and 3.   

Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org