[Zope] comment on posting behavior

J C Lawrence claw@kanga.nu
Sat, 26 Feb 2000 22:20:04 -0800


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