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

Thomas Stenhaug thomas@src.no
05 Mar 2000 14:34:12 +0100


* Alexander Staubo

[many good points cut away]

| 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.

Not that I have very much to base a comparison on, but I regard Zope
as both stable and fairly speedy.  I think I can guess in what regards
an alternative could be faster, but I'd really appreciate to learn
where Zope lacks in stability.  Can you provide any references?

| 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)

I don't quite grok what "the situation" is referring to, but I think
you're wrong here, or at least mistaken regarding the meaning of
"proprietary".  Proprietary, according to Merriam-Webster, means this:

[cut from Merriam-Webster]
Function: adjective
Etymology: Late Latin proprietarius, from Latin proprietas property --
           more at PROPERTY
Date: 1589
1 : of, relating to, or characteristic of a proprietor <proprietary rights>
2 : used, made, or marketed by one having the exclusive legal right 
    <a proprietary process>
3 : privately owned and managed and run as a profit-making
    organization  <a proprietary clinic> 
[/]


[...]
| 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; 
[...]
| 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.

I'm not sure if I agree it's a problem, then, that Zope lacks in the
big-department. :-)

| [under Zope's surface] lies a powerful engine with scalability
| problems.

What part of Zope's engine are you referring to here?  Do you mean
Python in general, are some specific part?  Like ZODB?

| 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.

I actually thought of ZEO as a very nice way to scale Zope.

| 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).

It would be very much appreciated if you could share some specifics.

[...]
| Zope desperately needs native support for XSL/XSLT as an alternative
| transformation language.

I second that.

[...]
| 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.

You are right about that, and I think that's a better way to provide
such support, rather then building specific support for any of them
into Zope.


Thomas