[Zope] Zope needs this (and Dynamo has it)

[Alexander Staubo]

> 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