[Zope-dev] who wants to maintain Zope 3?

Martijn Faassen faassen at startifact.com
Tue Apr 14 11:33:23 EDT 2009


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



More information about the Zope-Dev mailing list