Forgive the generality of this comment, but I think one of the biggest things going for Zope is that it takes some hard integration problems and makes them simple. - ZEO makes object persistence cluster, and without really needing to do much to your applications (other than have good conflict-handling code in your applications to deal with increased storage write latency for the network, and handling cache invalidation mechanisms). So for the most part, clustered persistent objects allow things like shared sessioning across your cluster to just work. Scaling becomes less of a development issue and more of an integration/sysadmin issue, like it should be. I'll go out on a limb to say that Java is going to make you work harder to not only get close-to-transparent object persistence, but making that scale and cluster will be harder, and certainly you will be tied down to one particular ODB or serialization/storage framework vendor; ZODB is more open and more-or-less a standard for Python folks. ZODB makes transactions easy too. - Have you showed your management some of John Udell's latest InfoWorld columns? ("Shipping the Prototype" and "Refactoring the Enterprise")? http://www.infoworld.com/article/03/02/06/06stratdev_1.html http://www.infoworld.com/article/03/02/13/07stratdev_1.html - The Plone folks have plugged in their 1.0 press release that they support the first "industry standard templating language" (paraphrase) in Zope Page Templates. Since there are implementations of PT/TAL in other languages now, you could argue that for the presentation layer, you get something cleaner and more standardized than the popular (but platform specific) JSP type solution. - Make the case for Python; Zope naturally follows. One ROI factor for the suits could be explained in terms of lower post-project "is done" expenses (and therefore less risk), and that the language will enable your project to be maintained without high-cost in the long term, which decreases (a) the risk of scrapping the project 2 years down the line (because you can adapt easier), and (b) the risk that you will need to spend big $$ on major changes. Python lends itself to the "embrace change as inevitable" school of thought, and gives you something easier to manage changes in the system with. I think Udell's two articles go far to make this plug for "scripting the enterprise." Plug Python's use for Star Wars at ILM, Google, etc. I would also argue that Python makes it easier to write code in terms of your application, rather than make your business fit your technology or spend most of your time writing "bridge" code to make the two connect. See http://www.python-in-business.org/success for case-study type blips as to folks using Python. - Scalability: plug ZODB's storage-agnosticism to your management folks. You can use FileStorage, you can use BerkeleyDB storage, you can use DirectoryStorage (which will scale quite well, has tools for incremental backup and replication, and you can also use standard Unix tools too - works quite well for high-availability clustering), etc. On top of various object storage mechanisms, there is now a great mapping storage in AdaptableStorage, which allows you to write plugins to serialize object data to pretty much any mechanism you could think of (RDB, XML, LDAP, etc). This flexibility (with mostly free, easily available, vendor-agnostic software) is likely to be better and cheaper than what you might find in the Java world, where these things are less standardized, and more vendor-specific. Personally, I think the lower-costs, lower-risk, more flexibility arguments go pretty far. Java, as a popular platform is a low-risk platform, but it does this by moving the risk to the application (forcing you to deal with object persistence or serialization, transactions, sessions, etc, choose competing implementations of 3rd party technology - batteries not included) and making the developer compensate to keep the risk low, but this makes costs high. Zope, like Python has batteries included for a lot of things that are traditionally application-developer's problems, and removes some of the complexity away from having to do it yourself. Java's popularity, on the other hand, encourages choice, but also forces it on you as well, by playing to the hands of multiple vendors for app servers, object database technology, etc. Zope's integrated nature makes it easier to get started quickly without costly vendor or 3rd party technology commitments that may turn out to be a poor match. Python is less popular, but decreases the risks of your project, which ultimately is what really matters much more than the platform. I hope this is somehow helpful. Sean -----Original Message----- From: Samir Mishra [mailto:SamirMishra@cbuae.gov.ae] Sent: Sunday, March 02, 2003 1:08 AM To: 'zope@zope.org' Subject: RE: [Zope] Help Needed - Case for Zope Thanks everyone. Any Project managers out there with something to add with regard to comparison between speed of implementation for Zove vs. other products? Personally, I place maintainability and transitioning skills as my top priority, and elegance of code comes last. Speed (e.g., of the server) is a non-issue because one can always allocate better hardware for this since it's a mere commodity now, intellectual capital is always at a premium. And that's why I like Zope :) But I still have to sell the concept to managers who only hear "Java" & "JSP" from software vendors and so are most familiar with these technologies. Samir. -----Original Message----- From: Paul Browning [mailto:paul.browning@bristol.ac.uk] Sent: Sunday, March 02, 2003 11:58 To: 'zope@zope.org' Cc: Samir Mishra Subject: Re: [Zope] Help Needed - Case for Zope --On 01 March 2003 21:52 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Samir Mishra wrote at 2003-3-1 14:26 +0400:
My manager has requested comments on whether Zope "performs like a dog". I'm > doing some digging around at the moment, but, in the meantime, if anyone has > any links to recommend, benchmarks, experiences to share, that I can use to > counter his 'assertion', it would be much appreciated.
One way of getting Zope "run like a bow-legged terrier on sleeping pills" (Pieters, M., pers. comm.) is to use multi-processor Solaris without paying attention to the threading issues (see <http://www.zope.org/Members/glpb/solaris>). If you're starting from a clean sheet it's probably best to avoid Solaris. Paul -- The Library, Tyndall Avenue, Univ. of Bristol, Bristol, BS8 1TJ, UK E-mail: paul.browning@bristol.ac.uk URL: http://www.bris.ac.uk/ _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )