Comments on: What Zope can learn from Mozilla

By: Chameleon: byte compiler for ZPT and Genshi « philiKON - a journal

Chameleon: byte compiler for ZPT and Genshi « philiKON - a journal — Wed, 22 Oct 2008 10:40:28 +0000

[...] match for Alex Limi’s proclaimed faster and lighter Plone 4, next to ditching Archetypes, reducing the Component Architecture overdose and going more [...]

By: Tres Seaver

Tres Seaver — Fri, 19 Sep 2008 19:54:53 +0000

The CA is used once, at the start of the request, to look up the traversal policy: the default
implementation for “graph-like” sites is the __getitem__-only one I described to you. See:

http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/traversal.py (in ModelGraphTraverser’s
__call__)

for the implementation, and:

http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/router.py (in Router.__call__)

for the point at which it is looked up.

By: Robin

Robin — Wed, 17 Sep 2008 23:49:14 +0000

Mono is mentioned in the quote. What does Mozilla have to do with Mono?

By: Martijn Faassen

Martijn Faassen — Wed, 17 Sep 2008 20:06:54 +0000

Chris, Tres gave me the understanding that repoze.bfg doesn’t use an adapter lookup during traversal at all. Sounds like I need to look at the code.

By: David Pratt

David Pratt — Wed, 17 Sep 2008 13:06:02 +0000

Hi Phillip. I agree with much of what you have to say here about zope. If you are serious about this direction, it may be better to lend support to repoze or set up a repoze track in zope’s repository for this purpose. It is possible Zope’s future may be best a library of packages than as a framework itself.

Consistent with your post, I also felt some urgency to change course with my own work as a result. Zope is becoming non competitive with other frameworks comparatively on resource utilization. This is a key motivator for me. Much of this is due to the large number of dependences of zope which can only be sorted but will require some considerable time.

I see the publisher, global registry and dependencies as the major (but not impossible) changes to zope. In fact, it would create a new zope if undertaken. Keeping backwards compatibility would be a real concern for pure zope consumers. Given zope3 is also readily consumed by zope2, I can see any real changes being a real mess for the Plone folks (that already straddle two incarnations of zope). Reducing dependencies helps zope and other frameworks consume zope packages. At some point, with the framework notion, you have to start over again. This is what Chris has done with repoze.bfg in an innovative way.

At the same time, repoze.bfg does not throw out the baby with the bath water with CA. You can fully use Component Architecture of zope which is important to me. It also takes advantage of martian (the important development of grok) as an alternative means for registering views. I am using repoze for a project and what I like about it is the following:

1. Component Architecture: Full use of CA
2. Publisher: provides alternative routes traversal mechanism
3. Reworked Global Registry: Multiple apps are able to operate within a single process. You can forget about sites concept in zope to provide full isolation between apps or sites.
4. Development Speed: Development speed is fairly fast and an alternative decorator available to register views.
5. Simplicity: It offers development simplicity and decreased volume of everything decreases. Its like breathing fresh air.
6. Footprint: Without the dependency issues associated with zope. A app will start in the 20MB range or less (less than half footprint of a basic zope install)

I guess the biggest question is really what zope should be in the future. Personally, I think you would need a zope4 to pull existing zope components together into another notion of a framework. If this were done it would look alot like repoze.bfg.

By: Alec Munro

Alec Munro — Wed, 17 Sep 2008 12:49:19 +0000

I would be very interested to see where this goes, and help out. I’ve spent a lot of time on both sides of the CA fence. I appreciate it’s elegance conceptually, but I’ve often been bitten by implementation details.

By: chrism

chrism — Wed, 17 Sep 2008 12:33:55 +0000

I’ll venture this suggestion.. the bfg “router” (aka publisher) allows for traversal customization via a single interface indirection (ITraverser). It would be very simple to plug an alternate traversal policy into it. It’s also not at a point where it can’t change (unlike the z3 publisher), so even if it didn’t quite do what grok needed, it could be made to do so.

By: Martijn Faassen

Martijn Faassen — Wed, 17 Sep 2008 12:08:55 +0000

Note also that my intended “neo traverser” doesn’t actually forgo the use of the component architecture completely. I think it’s still very useful to have an adapter lookup for each traversal step for instance. The code that does all this can however hopefully be a lot simpler to comprehend, and not be quite the scattered ravioli code that the current Zope 3 publisher is.

http://c2.com/cgi/wiki?RavioliCode

By: Chris McDonough

Chris McDonough — Wed, 17 Sep 2008 12:07:19 +0000

i think philiKON was referring to the middleware parts and not bfg… bfg sort of violates the repoze “share with other people and let other people share with us” repoze mission statement (in our defense we did need some very small core on which to build apps ourselves).. but the actual repoze focus is pretty much still the same.. make libraries that all python programmers can use without buying in to the CA.

By: philikon

philikon — Wed, 17 Sep 2008 11:59:20 +0000

You’re right, repoze.bfg uses the Component Architecture for a specific usecase, looking up views for models. This is still a very useful application of the CA.

Note that I actually didn’t mention bfg at all in the text because it’s not much of interest for Zope. Bfg is a minimalistic web framework while Zope and Grok want to be mega-frameworks.