From: M. Adam Kendall [mailto:mak@kha0s.org] Sent: Friday, March 03, 2000 5:48 PM To: Alexander Staubo Cc: Zope Mailing List (E-mail) Subject: RE: [Zope] Zope needs this (and Dynamo has it)

On 03-Mar-2000 Alexander Staubo wrote:

...

are possibly evil, but the product is of high quality, and it sells. And because it sells, many people use it, and because so many people use it, skilled developers exist in large numbers. Unfortunately, I can't say the same of Zope.

Funny, I had never heard of Dynamo before you mentioned it here. Fortunately, I can't say the same of Zope ;)

The reason you have not heard of Dynamo is that Dynamo isn't being hyped; Zope is. There are other, non-Zope solutions out there, some of them quite solid. I like to keep an open mind, and so should you. There are, indeed, quite a number of people who have heard of Dynamo but never heard of Zope. While my statistical data is entirely non-existent, I'll wager that Dynamo-awareness exceeds Zope-awareness by a factor of at least two. ;-) This isn't necessarily something to get upset about, and anyway I believe, and hope, that the difference is shrinking.

I think you underestimate the actual numbers of people and sites that use Zope. I also think that you are creating FUD so that you can get a feature you want to see implemented by the folks at DC. Truly bad taste.

Just a bit of background since you're accusing me of FUD. Dynamo drives many of the web's most popular sites, and is in direct competition with Zope, sharing the application server space with contenders such as SilverStream, Sybase, Vignette, Jade, and many others. Along with Vignette, Dynamo is one of the most successfully and widely employed app servers solutions in existence. Whether this is a good or a bad thing I'll leave for you to decide; I don't like Dynamo, but I acknowledge its technical edge on Zope (and other solutions) in several areas, such as clustering, reporting, personalization services, e-commerce services, stability, and raw speed. As an artifact of Dynamo's platform of choice -- Java -- there is indirectly a "virtually limitless" expertise on Dynamo. If you know your Java and your Enterprise JavaBeans, you already know Dynamo, and stepping into your Dynamo shoes will be easy. Compare that to stepping into Zope's multiple zens: acquisition, DTML, objects, Python. Note that I'm not arguing against Zope here, which has a self-inflicted and justified learning curve. However, managers will not necessarily respect this difference in philosophy: The cost of training a person in the arts of Zope will be measured against the cost of hiring an already-trained Java wizzkid, and -- at least right now, today -- Zope will lose. This situation has nothing to do with open vs. closed, either. Just like Zope we're talking about proprietary (as opposed to standarized -- DTML may be open, but it's still proprietary) technology. The fact that Java is more widely established, and evolving faster, than Python is unfortunate and outright infuriating, but right now that's how the cards are dealt. Dynamo also costs a lot of money. For small businesses, it costs too much. A heavy-duty support contract with Digital Creations also costs a lot of money, but you have a choice. On top of that, Dynamo is open-ended but not open -- there is no source distribution. My point? Zope already has a foothold in the small-time web site segment of the market. However, big people wield big swords, and Zope, despite its many powerful features, is not big enough for truly big things. This is a two-part problem. The first part is that Zope's bullshit factor is too low; it's not flashy enough to convince a senior manager that Zope has enough clout for their business. It's a purely aesthetical apprecation of Zope's poor-man, open-source philosophy, and the fact that Zope does not offer a comprehensive monitoring system with a ticker bar providing useless but impressive information does not fare well with those who like to be bullshitted. We tech people know better, we know a shiny surface tells us nothing about the engine underneath, but we tech people are not holding the crucial component -- those big brown bags of money. Now, the second part of the problem is that underneath Zope's lacklustre but entirely deceptive surface lies a powerful engine with scalability problems. So far the only way to scale properly with Zope is a combination of a load-balancing clustering system (eg., TurboLinux' TurboCluster Server, which I can personally vouch for -- brilliant stuff -- or Linux Virtual Server) with Digital Creations' ZEO, of which I've only read about. There are Zope sites out there that are suffering scalability problems (I won't mention specifics, other than that the project I'm involved in is one of them). The problem is real, and intrinsically related to Python. I wish I fix Python rather than sit still and bitch about it; I periodically express my dissatisfaction with Python's lack of performance, and I have certain ideas as to how to improve it, but a research project like this would take time, of which I can currently allot none. So instead I just bitch. ;-) Finally, as for DTML being proprietary, Zope desperately needs native support for XSL/XSLT as an alternative transformation language. I think it was Michel who spoke vaguely of this being considered incorporated into a future version of Zope. (At one point I planned doing an XSL product, but I have not yet had a project to fund it with. So I'm not just bitching here.) We also need better in-line scripting capabilities than currently offered with External Methods and PythonMethods. This to fight the creeping and ever-expanding notion that Java (replacing Smalltalk) is the chosen, possibly even pre-destined, language for app servers and middleware. Try to find an OODBMS, RDBMS, or application server nowadays that does not use, or plan to use, Java as its fundamental extension mechanism. I can think of a few, but they're few. If you want to talk about FUD, you've got it right there. Anyway, just my two cents.

...

Speaking of which, SNMP support for Zope would have been nice. Then we could import the numbers needed to build monitors like the one featured in the screen shot.

Please no. There is NO reason to pollute Zope with something as insecure as SNMP.

Then please offer us an alternative, open, standarized interface to monitoring data. The fact that SNMP in itself is insecure has little, if anything, to do with whether Zope should be "polluted" with such support. An alternate route might be to have Zope export necessary variables through a well-defined XML DTD, and then provide the necessary tools to convert this XML output to SNMP, although supporting SNMP traps this way would be difficult. Perhaps supporting Performance Co-Pilot (http://oss.sgi.com/projects/pcp/) would suit you better. Unfortunately, PCP is probably not -- at least not now -- portable to Windows NT. In fact, I'm not sure whether PCP will exist outside IRIX and Linux for some time yet. As far as pollution goes, assuming Zope exports the appropriate data -- in whatever form -- then support for performance/monitoring/management APIs such as SNMP, PCP, WBEM, and to a lesser extent PDH, aren't difficult to isolate into add-on products. -- Alexander Staubo http://alex.mop.no/ "Do not go gentle into that good night/old age should rave and burn against the close of day/Rage, rage against the dying of the light." --Dylan Thomas