Tim Hoffman wrote:
> 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
> 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?
> 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)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -