Hi!
I listened in on the chat regarding this and although I think the idea has merit, I'm not sure that it is vitally important right now. It could too quickly turn into a lot of burned time with nothing to show for it.
Tim, that's a good point. Though I am quite enthusiastic about having a more component-based architecture for Zope, it has to be at a reasonable "cost".
Right now, I think that 2 things could flatten the curve for new developers that are more accessible: 1. Rewrite ZClasses. This is currently an ominous threat that could break much backwards compatibility. Many ZCers want this to happen too. So let's make it happen now, and break less rather than more. 2. Simplify the security model more, if possible :) I know, it's been done, but it's still not easy.
These two issues can be found in various partly overlapping Fishbowl proposals and initiatives. I think that a lot of people are waiting for them. For security, see the latest threads I and Michael Bernstein have started ;-) One of the important points to make is that ZClasses (or a replacement for them) as well as the security model are frequently used by Zope users (or "configurators") , while the new components model will mainly be a benefit for Zope programmers (i.e. people working on extending Zope rather than just using it). So their impact might be much larger ... If I was asked, I'd say the most important things to do in Zope are "better ZClasses" or whatever can replace their functionality and a more robust and better-to handle security. If all this can be done in a component-oriented way, this would be great. ;-) So the component architecture is more like a paradigm that should be used with new projects than a new "Product" or whatever on its own. Joachim BTW: I missed the chat. Will there be a transscript somewhere on zope.org?