[Zope3-dev] Re: One namespace for ZCML

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp von Weitershausen wrote:
> Tres Seaver wrote:
> 
>> - The opposition to namespace declarations is whiny, as they are the
>>   standard way to make XML extensible.  Unless we are going to quit
>>   using XML, outlawing namespaces would be equivalent to saying, "you
>>   may not extend ZCML";  I don't think we are smart enough to make that
>>   ukase.  I think the Last Law of Python according to the Prophet
>>   Peters obtains here as well.
> 
> 
> I'm neither trying to follow the whiny people who detest XML and
> therefore ZCML nor am I trying to make ZCML not extensible. That said, I
> think that ZCML's usage of namespace is quite arbitrary. Why is browser
> and mail-related stuff on its own namespace but security-related stuff
> not?

I'm not arguing (here) against refactoring the namespaces in which
"core" directives are declared.  I'm arguing against the idea that
namespaces are bad in general.

> Why is it then recommended that third-party packages use their own
> namespaces, even though they might only have browser-related directives
> to register...?

Third-party packages which don't define new directives don't need their
own namespaces.  If, for instance, Plone adds a "plone:view" directive
which is nothing more than a no-op wrapper around 'browser:view', that
would be a Bad Thing (TM).  If, however, they add a 'plone:frobnatz'
directive which does something magical and outside the scope of the Zope
core, and document how to use it when setting up Plone, that would be a
Good Thing, especially if it kept people from changing "site policy" by
customizing software.

> I don't really see the point in ZCML's using namespaces. What good do
> they provide? Seriously, is it just the prefix? Well, we don't need the
> namespaces for that.

ZCML *must* support extensibility, and therefore must continue to allow
packages to register their own namespaces (unless we abandon XML
altogether).  Otherwise, we give up the ability to check that a given
directive can actually be interpreted at all, which would be a Bad Thing.

>> - Note that the non-XML language also used by Zope (ZConfig) has its
>>   own extensibility mechanism:  in fact, Fred and I made it possible
>>   in November for Zope2 products to register their own schemas for
>>   those extensions, which was a blocker for moving some configuration
>>   out of software.
> 
> 
> I'm not sure what to do with this info...

Just note that being able to extend the configuration language from
non-core code is an important use case.

>> - I don't want to encourage people to do configuration in Python:
> 
> 
> Rest assured neither do I.
> 
> 
>>   we have moved away from that *on purpose* in Zope, and I don't see
>>   a reason to go back.  Directives which make it possible to change
>>   policy decisions without touching software are a Good Thing.  I think
>>   that letting people who spend their days up to the elbows in the
>>   software make choices here skews the picture:  we *want* people to
>>   be able to change the behavior of the system in controlled ways
>>   without having to modify software;  I would prefer to hear feedback
>>   from non-core-developers before going further with the "ZCML delenda
>>   est" thread.
> 
> 
> I have heard such feedback, otherwise I wouldn't have taken the time to
> write the proposal. I've also heard positive feedback on this particular
> matter (reducing ZCML namespaces to one). Again, I wouldn't have brought
> it up otherwise.

A lot of the feedback seemed to be along the lines of:

  - "ZCML sux -- I won't use Zope3 until it is gone!"  They weren't
    gonna use it anyway.

  - "Why do I have to declare the namespaces?" (XML haters, for the most
    part;  note that I am not an XML fanboy myself).

  - "Why does the core use more than one namespace?"  This question
    seems legitimate to me:  I think we wanted to allow non-mangled
    names for otherwise conflicting directives, e.g. 'browser:view'
    and 'xmlrpc:view'.

>> - The "application vs plugin" discussion is probably germane to this
>>   issue, as well:  a user who is deploying a single application is
>>   acutally *more* likely to define and use convenience directives
>>   which reduce the amount of effort required to change policy than
>>   the generic appserver-with-plugins configuraiton.  Removing the
>>   ability to create such convenience declarations makes it harder
>>   for those developers.
> 
> This belongs in the other thread, really. But here it goes anyway:
> 
> I'm not convinced that people who deploy apps will actually go as deep
> as editing package ZCML, or even overrides for that matter. I would
> rather imagine they turn ZCML features on or off (which would then turn
> on or off ZCML directives via zcml:condition)

Nope.  You are ignoring the cases which are currently done TTW in Zope2:
mailhost configuration, for instance, or caching policies, etc.  If
an application wants to add a diretive which makes it possible to
configure such policies in ZCML, why should we prevent that?

>> - Many of the objected-to directives exist precisely because people
>>   did not want to type the much more verbose equivalents which were
>>   the original, "cleaner" spellings.
> 
> Or perhaps people just thought that people wouldn't want to type in some
> extra stuff. Because I think they do if it helps them remember and
> understand better.

The origin of the "dead chicken" meme, was Guido (and others) who
objected to the mistake-prone typing required by the earliest set of
directievs we had;  Guido called them "dead chickens".


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD8LP6+gerLs4ltQ4RAuoRAKCAlLEORfvO7tp120QAQhv3lTQ7JACeLgxt
NeUfI9mQ5TWhRO+typeHKcg=
=8EfQ
-----END PGP SIGNATURE-----