Tim Hoffman wrote: [snip] > It seems from all the discussion of late that we might of chosen a > architectural dead end (though I don't think so).
It's definitely not an architectural dead-end. I think the codebase we used to call Zope 3 has been evolving faster in these few months in 2009 than it has in many years, and I hope to keep up this energy. It's just that most of that evolution is in the Zope Toolkit layer. I know that the Grok and Zope 2 people have functional mechanisms about maintaining the stuff they build on top of the Zope Toolkit (including writing documentation, etc). I want there to be awareness that we need people willing to chip in maintaining the Zope 3 bits too (and that we need to work on figuring out what these bits are). If people are *not* willing, there's a risk that it won't be maintained. It could also be that we decide to rename Zope 3 to something else (to get rid of some of the confusion with Zope 2), but that's a separate debate I think we should separate from this and we'll let that rest for a while. > If someone where coming to the Zope party now and needed the full > blown security model and view mechanisms, and the zcml tied to that > model what would the choice be going forward? Zope 3. > repoze.bfg has pretty much gutted that model (which is fine as a > simpler model is definately required, I am planning to revisit bfg > with my zope on gae work) > > grok sort of fell in a whole for us when we started the project as it > wasn't obvious how to go about doing the full security model etc... > (mainly I think because a lack > of docs etc... when we made our decision) Grok currently doesn't support the full-blown Zope 3 security model, though there's definitely a wide interest in adding this. It hasn't happened yet though - it just needs people to sit down and do it; I think it's fairly low hanging fruit. > Any thoughts on this decision, direction that we have taken, and what > if could be the alternative if the Zope 3 app server itself withered? If the Zope 3 app server withered, if you want compatibility with the existing story, I'd go for Grok + full security checks model, as I assume it *will* be created. If you don't need or want compatibility you could explore bfg. That said, I have good hopes (and doing my best) to make far more of the Zope Toolkit libraries stay relevant than just the small selection that BFG uses. After all, Grok and Zope 2 and presumably also Zope 3 in some form will still be around! I think the basic Zope 3 approach works pretty well (especially with Grok-style configuration) and I think there's quite a bit of evolution possible to make it a lot better (aggressive WSGI-ification and a much increased focus on user interface components are two areas I want to look into next) Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )