Even though I think it is pointless, I am going to reply to some of the points you make.
On Saturday 14 January 2006 11:51, David Johnson wrote: > The documentation is not well defined, which makes deployment dangerous > because one may produce an application that does not conform to future > releases of Zope. I have absolutely no idea what you are talking about. A lot of the packages in Zope 3 have text documentation files that define the API very well. Furthermore, the interfaces document the API on a programming level. Tools like API doc pull a lot of this information (and much more) together. Other than that, there are many beginner tutorials out there now and we have 2 books. We commit to an API for 2 releases after it is deprecated. If you find that a new release breaks your code, then you can consider it a bug and report it. > Configuration is done through a series of configuration > files, which are easily broken and difficult to traverse. If the > configuration is damaged in someway through a mistake or other reason, the > server will not restart until it is fixed, which presents serious > challenges in a production environment - in the heat of the moment, wading > through errors is not trivial, especially for the non-Zope experienced > system admin who will be on call at 2:00 AM. The errors are difficult to > comprehend and do not easily point out where problems lie. Once problems > are found it is difficult to understand what they mean. First of all, if you break any configuration file, not just Zope's, an application will not start. Note that someone should never mess with the ZCML files directly. Use overrides.zcml to make your customizations. As to the production system, if you change configuration on a life production system, you are plain stupid. Also, the system administrator should *never* mess with ZCML. ZCML is application developer domain, not system administration. Also, I don't understand why a crashed server would cause anyone to mess with ZCML on a production system. I sincerely have no clue how you came up with this. > I can only find one semi real-world Zope 3 example (the SIP application), > and it does not even run under Zope 3.2; Aehm, not every application Zope 3 is used in is a public project. Here are other applications that have been deployed: - Zope Corp. Document Management System (closed) - Tiks, a CMS for Zope 3 [a fairly large Web site has been in production using Tiks] (open) - Another large document management application, which I do not know the name of - Launchpad and other Ubuntu-related software - SchoolTool/SchoolBell; I know that SchoolBell is used in several schools and universities around the world. These are some of the pure Zope 3 projects I know about; there are surely many that use Five. > while I've been able to wade > through and fix many errors, I continue to get more as the interfaces and > standards keep changing. If people do not report API breakage, then we cannot fix it. I tried very hard to provide good backward-compatibility, but it's not an easy task and problems are expected. > Even the current i18n facility does not seem to > work properly, editing messages frequently gives errors and does not update > properly. SchoolTool uses the i18n facilities heavily and we have never had update problems. Are you sure you know how GNU gettext works properly? > Errors in general seem to give unexplainable results. Could you give examples? > I do see many advantages to Zope 3 and I am willing to tolerate a lot > because of those advantages, but it seems like it not quite polished yet, > and there may be some architectural issues that are problematic for > real-world use. You have to be much more specific to provide constructive feedback. If you are unhappy with some part of the architecture, make a proposal or at least bring it up on zope3-dev. > Has anyone produced a significant application in Zope 3? Yes, see above. I am personally involved in SchoolTool and it is pretty big and stable. We have had no problems that are due to Zope 3 issues. > Has it been relatively bug-free? Yes. We do not get too many bug reports. Most of them are not even very serious. Note that Zope 3 is one of the first (if not the first) Open Source projects that uses test-driven development. All tests always have to pass before a check-in can be made. > Has it integrated with an RDBMS? Zope natively uses the ZODB, which most Zope 3 application developers prefer to use. It also depends what you mean by integration. Zope 3 supports connecting to RDBs using utilities and making queries that are integrated in the transaction mechanism. If you want higher-level integration, there is sqlos. Nuxeo is working on an even higher level API to interface RDBs with Zope 3. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training _______________________________________________ Zope3-users mailing list Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users