The *only* reason for an XML based configuration is if you’ve got an external tool that needs to communicate with your application – and that tool is dedicated to creating configurations. I haven’t seen that much… and in the meantime we’re all stuck fucking around with XML.

Regarding your other points, my previous response about removing XML from Zope was insufficiently detailed. I agree with you re: layers and such, and sure you can’t just snap your fingers and immediately swap out a system component. and replacing ZCML is different than laying on top of ZCML. OTOH, if ZCML were replaced by a Grok component, it should be seamlessly integrated into Zope. One shouldn’t have to switch into Grok-mode; it ought to feel natural and without a context-switch. I presume you’d agree with that goal?

I see you’ve elaborated on this matter at length, on your blog.

We’ve done that in the course of the last two years. Grok has an alternative configuration system for Zope 3, and it’s mostly just about writing the code you’d need to write anyway; you can just leave out the ZCML. It reuses most of Zope 3′s configuration infrastructure (and is compatible with it), just gets rid of the ZCML.

It’s a layer. It doesn’t layer on top of ZCML; it replaces the XML bits of the ZCML layer. Software is made out of layers, or at least components that use other components. You just want good layers, and not too many of them you need to know about at the same time, as that is confusing and frustrating.

Unfortunately you can’t just rewrite a large code base like Plone to be simpler, as there’s a lot of value in it. Plone wants to move forward. This will lead to the introduction of new ways of doing things and the old ways typically can’t just be removed right away.

My hope is that Plone can move forward in a measured way, step by step, to a system that’s less complicated for people to learn. That’s up to the Plone developers to develop – I’m just saying Grok technology is here today and can help.

P.S. I understand that the context switch between code and ZCML is frustrating and not conductive to rapid development (that’s why I helped kick off the Grok project). But I’d also at least try to study the history of why the “XML crap” is there. Thought went into it, and while I don’t believe it was entirely the right direction, it isn’t entirely the *wrong* direction either. Don’t throw away the good ideas along with the ones that didn’t turn out so well.

What’s not to like? Granted, the venue wasn’t very condusive to a sociable lunch, but the lunch itself was good!

But, wouldn’t you agree that rather than layer another tool/framework on top of Zope, it would be better to remove the XML crap from Zope? Like maybe in Zope 4?

@Malthe: +1 re: your venue comments. They did a decent job of camouflaging the external barricades, but after a couple of days the security got to be a drag. I understand its need, but I’d rather not deal with it every day…

I wonder how it affects your personality to live and work there.

One of the most important aspects of a conference is to be able to socialize, enjoying a good coffee, having a nice lunch etc, ––– in a comfortable space! I think most will agree that Reagan was unfortunately none of that.

But it’s a challenge to have a conference in Washington DC; it’s a rather uptight city, with a lot of security paranoia; ultimately, given the challenges, Alex and friends did a great job. However, future bids should perhaps go to destination that are more accomodating, not only central.

Oh well. TEHO.

The lunches were AWESOME. Absolutely awesome. I remarked to a few people that the quality would actually put me off hosting a plone conference out of fear of not being able to compete.

Using Python for configuration files is fine. In the past we’ve noticed however that sometimes this leads to unholy mixtures of code and configuration, especially if confined with not-very-well-designed configuration UIs.

The reaction to that was ZCML: a designed configuration system where we had a domain specific language to do configuration. The main drawbacks: violates DRY, scares off Python developers.

The reaction to that is Grok. We deduce configuration from the Python code that you need to write anyway. No separate configuration files, just your code, with a few extra hints to the configuration system where necessary.

All this is coming to a Zope 2 near you.