I dislike being an apologist for any product. I apologise for that aspect of what follows. On Sat, 26 Feb 2000 19:28:28 -0500 Guy N Hurst <gnhurst@hurstlinks.com> wrote:

This is only to underscore the fact that Zope is not ready for prime time. It goes beyond just posting untested results.

No, it indicates that the Zope community, and its accumulated wisdom is yet young, which is a rather different thing from readiness or physical capability for "prime time". This does not state that Zope is ready or not for "prime time" (I'm not fit to make that call), it just doesn't apply to the question. A implies B does not mean that B implies A.

Something like Perl or PHP would have definitive, known answers for most all issues.

Which is a fact due to a well established and articulate user population more than anything else. Zope could be the best thing since sliced bread or your choice of &diety; on high, yet suffer as it is suffering, without a skilled and articulate user population.

MY OPINION The problem with Zope is, hardly anyone seems to know what is really going on under the hood (but hey, you're not supposed to need to know), and it is too often that it is left to anyone's guess why something doesn't work - or even why it in fact does work a certain way.

Which is why the source is available: you can find out for yourself. The assertion that "you're not supposed to need to know" is not supportable, and is I suspect, a FUD-like red herring imported from other fields. Zope has the rather unusual property that it was written in the same language that is used internally for extensions, and that such extentions are expected and intended to directly and intimately integrate with and extend Zope itself. (One could argue that this is a failure in product definition deliniation, as well as argue that this is one of Zope's strengthas as an ___object___ publishing system. but that's something for another argument).

No one is certified...

Praise be.

...and no one claims to be, either.

A small and wonderful mercy.

whereas Perens' site had almost no graphics...

Serving graphics from Zope is patently silly. Serving graphics from any large general purpose server (eg Apache) is patently silly for active sites. Static content should be, and needs to be, served by small, fast, light weight single-purpose servers ala thttpd. Its just not worth devoting a near-Meg process image executable to shoving a 1K JPEG down a wire.

...and FAST CGI isn't supported on NT for free.

NT is a choice. Like any choice, it has implications. You either buy the implications with the choice, or you make a different choice. Don't like the trade-offs? Sorry. Life is tough and often unfair. I'm not aware that Life, or Zope, promised to be fair in this regard. If you want to use NT, that's your choice, and not one I'm in a position to discuss (happily MS free for almost 8 years now). Ther are many trade-offs in making the NT choice. Apparently FCGI is one of them.

Comments? Is anyone else fed up?

I have not mastered Zope. I have not mastered Python tho I have written a few hundred thousand lines of Python in recent years. Zope's learning curve is near vertical. Zope does not appear to either be, or to present itself as a general purpose hand-holding user-protecting RAD web publishing or web scripting system. It is presented as an OBJECT PUBLISHING SYSTEM, which is a rather different thing, and is a thing which directly implies that you are, at some point, going to need to apply Object Oriented Design (OOD) principles to its application. I make my living as a C/C++ programmer and am reasonably familiar with OOD. I'm aware that OOD requires discipline and good design skills to either apply well or to reap the benefits of, and that given those abilities, well applied, that the benefits are present and can be significant. Ergo, Zope, as an object publishing system suggests that by applying the same disciplines I use elsewhere in OOD, I can gain similar benefits for Zope's problem spaces. I haven't seen any sign that this isn't true. (This doesn't mean however that I am unconcerned however at the lack of abstraction between user-code and Zope internal code, tho that "fault" can be laid mostly at Python's lack of an internal security model). Mostly I've seen ways that actively suggest and imply tht this si true and can be relied upon to be true. As always, this is perception, and YMMV. Lastly, I trust the opinions of those who have mastered a particular skill, or who have at least shown good competence there. I do this deliberately on the basis that they have demonstrated that they actually understand the topic in question and therefore have a reasonable chance of actually being able to judge it on its flaws and merits. Its a lot harder to value the judgements of one who has stated that they have failed to either understand or apply the material they are now judging. The fact that you are (near) universally condemming of Zope, rather than stating both strengths and weaknesses, areas in which it does well and ones in which you adjudge it falls short as all systems have good and bad points, further supports the view that your view is tunnelled, single-sided, and likely unfair to both parties. -- J C Lawrence Home: claw@kanga.nu ----------(*) Other: coder@kanga.nu --=| A man is as sane as he is dangerous to his environment |=--