I've proposed that a couple of times already. There are two problems in real life: 1) "Somebody" has to take care of managing the project.
2) If politics take over, things will quickly fall apart.
I agree. I hope that Heimo & Paul's session at EP will help work through some solutions to these points.
I disagree that performance is a problem in Zope 2.
I've heard that a couple of times. But let's face it: Of course you can get Zope to deliver partly dynamic pages at high speed and if you use caching you can deliver pages at wire speed, but it will not be nearly as fast as a solution using Java or .NET/C# if we are talking about a lot of two-way traffic and CPU-intensive tasks in the back end, e.g. an online shopping mall, a booking system, or a groupware.
Well, the site I am talking about is a real-world, huge-traffic, highly dynamic, personalised shopping site and multiple bookings system which gets millions of visits a day. It performs very well under extreme load in test conditions, *even when you take squid out*: better than the previous Java solution.
I would take this as a pretty good indication that performance need not be an issue when evaluating Zope. Let's face it: there are plenty of badly-performing Java sites out there ;-)
I do agree that it is hard to find best practice information about this subject, though. I am planning to do a talk about it at Europython. If Chris M doesn't mind, I'll be using some of his material, and elaborating on it:
http://www.plope.org/misc/szweb
The reason the Zope site I'm talking about performs better, IMO, is nothing to do with the language, but to do with (a) the better application design and (b) the ease of scaling horizontally with ZEO.
seb
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
