Zope gives you too much rope?

[Andrew Kuchling]

ethan mindlace fremen <mindlace at imeme.net> writes:
> Whoa!  Almost all of the products we work on at Digital Creations are
> managed via CVS.  ZClasses, at the moment, are canonically used for
> interface items that really *should* be exposed through the web. 
> ZClasses still need some help, I'll admit.

I'm aware of that, but developing products is difficult and tedious;
only recently has some progress been made on not having to restart the
Zope server after every change.  Writing a simple object as a product
seems feasible; writing a complicated one seems like a recipe for
insanity.  
 
> And whilst you can't easily grep through files in the ZODB, this is a
> complaint that can be leveled at any database-driven web product.

Correct.  This is why all products that store code in a database *suck*.

> Well, you could ftp them in & out... ange-ftp works well, so if you're
> using emacs it's almost transparent.  Someone has written some bits for
> making ftp play nice with gvim.

I also like to use jed; that means I have to expend more effort on
writing the right glue for jed.  Somewhere users of nvi, pico, or jove
will have to do the same thing.  This is the problem with breaking
with Unix tradition and going out onto the island of storing code in
an object database.  If you threw tremendous resources at building an
IDE, like a Smalltalk or Lisp environment or IBM's Java compiler (is
it VisualAge Java where all your source is in a database?), breaking
with tradition might stand a chance of competing; without that vast
commitment, it doesn't.

> The security model used to strike me as overblown: now I think that Zope
> is one of the few web apps that takes security seriously.  I think this
> is a big thing, especially if you've got a lot of people working on
> stuff.

Perhaps, though I'm also doubtful because of the sheer volume of code
making up Zope, and auditing it seems difficult because you have to
audit everything since there's no obvious security-critical core.  But
if code can't be written through a Web interface, no security model is
needed at all, which is certainly simpler!  And that's our primary
criterion.

--amk