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

[Alexander Staubo]

> From: Thomas Stenhaug [mailto:thomas@src.no]
> Sent: Sunday, March 05, 2000 2:34 PM
> To: Alexander Staubo
> Cc: Zope Mailing List (E-mail)
> Subject: Re: [Zope] Zope needs this (and Dynamo has it)
> 
> 
> * 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?

It is very stable, indeed, so I take that back. ;-)

There are cases where I have been forced to kill Zope processes that
have falled into some sort of coma, but I've written these off as
growing pains in an evolving product. ;-) To date, Zope's stability
problems seem to have been mostly related to fragile database drivers.

I was really thinking of something else, and should have used another
phrase -- something like "high availability". Again, I have only read
the marketing material on ZEO, the product that supposedly provides such
features (load balancing, replication). Assuming ZEO works, strike that
from my list.
 
> | 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
>