RE: [Zope] Zope needs this (and Dynamo has it)
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
participants (1)
-
Alexander Staubo