Ken, those are all excellent points. However, we w...

2009-12-16T19:52:46.032-08:00

Ken, those are all excellent points. However, we weren't looking at Zope because we needed ANY of the things you identified. We have ALL of those things already with JBoss, Java, Groovy, etc.

We were looking at Zope to help us build those kinds of applications faster and easier than we already can. In the end, there just wasn't enough better about Zope to make us leave the JVM environment behind.

I would think that if you develop 'Enterprise&...

2009-12-16T18:03:04.852-08:00

I would think that if you develop 'Enterprise' software, then you'd also be running your prototypes/experiments in a clustered environment, whether you're evaluating Zope, Java/J2EE, or anything else you need to have really scale.

Since Zope has shipped with ZEO (Zope Enterprise Objects) and the ability to run numerous Zope clients (application server instances, where your business logic runs - the equivalent of your Pythonic JBoss, if you will), each taking advantage of one of your number of processors, this allows you to leverage your CPU to the utmost and you surely would be clustering if you truly are building Enterprise software, with needs such as fail-over and redundancy (not having a single-point-of-failure.)

Did I mention that Zope has shipped with this capability for over 10 years and that it doesn't cost a dime?

We've implemented truly Enterprise Zope deployments for large federal agency customers as well as entertainment/media sites, handling millions of web application visits (running the Plone CMS on top of Zope) for busy websites that have sporting events on CBS TV every weekend during the Winter/Spring. We do truly 'Enterprisy' things such as implement a load balancer, multiple servers, and multiple instances of our (Zope) application server. It works great and has for years!

As for the ZODB, did you ever stop to ask why you need a relational database? I'm not going to push an object-oriented database down anyone's throats, but I will point to the quite active trend toward ORM models in recent years (your folks are surely familiar with Hibernate on the Java side.)

Have you ever thought about the extra overhead of having this ORM (Object-Relational Mapping) layer that maps your nice object-oriented code to your relational data model?

Have you thought about the fact that much of the time, the performance bottleneck in an enterprise application is between the application server and the database?

Do you care about security at all and if so, do you realize that SQL Injection is one of the more common areas of breach for enterprise applications?

The ZODB addresses both these performance and security-related issues quite well, in my opinion, but you don't have to believe me on that. Zope is on the approved list of open source apps at the Department of Defense, and the Plone CMS that we run on top of it has been deemed the most secure CMS in the market (see details at http://cve.mitre.org.)

In any event, I don't doubt that you've hired bright people, but there are a lot of good things about Zope that it seems you're ditching for flawed reasoning.

Would I rather have Zope without the GIL, sure - but really only for NON-Enterprise clients/needs (where quad- or 8-core servers aren't in place), since I would be running multiple instances of Zope for my Enterprise clients anyhow.

I hope you give your smart team some additional things to review before you come to a final decision.

Best of success!

Grails won't disappoint you ;-)

2009-12-14T22:09:50.340-08:00

Grails won't disappoint you ;-)

Comments on Second Shooter: Why Zope won't Zip

Ken, those are all excellent points. However, we w...

I would think that if you develop 'Enterprise&...

Grails won't disappoint you ;-)