[Zope] To Zope or Not To Zope?

[Alexander Staubo]

Paul Everitt wrote:
[snip]
> > application server, and object database all in one package.  I have
> > managed to get Zope to run using ZServer + Apache PCGI, but the
> > performance seems quite quite dismal.  My concern is mainly
>
> We certainly haven't seen dismal performance.  Could you be more
> specific?

Actually, the performance on NT/IIS is pretty dismal, too -- it's all in
the fact you fork a new process for every friggin request. ISAPI on NT
and IIS [and others] and a mod_zope for Apache would be extremely nice.

[snip]
> As for compatibility, I realize that some people don't feel
> comfortable
> "locking" their database in a Data.bbb file.  We're taking
> steps to make
> this decision easier (e.g. XML import/export, Zope2's ability to store
> its contents in one or more relational database tables, etc.).  But
> those won't be ready for use for at least another month.

It isn't just an issue of compatibility, but also of speed, stability,
and scalability. Being able to have the Zope piggyback an MSSQL, DB2, or
Oracle server is definitely a huge comfort, because a _lot_ of man
hours -- arguably more than in the case of Zope -- have been put into
those RDBMS tweaking them and securing them. Instead of spending lots of
time finding new, esoteric ways of optimizing Zope's DB, you can
effectively delegate that work to people who have spend their whole
lives with their heads inside database algorithms. (Although I admit
that B-trees are nice.)

> > scale and compatibility issues, but most of the benefits of
> using Zope
> > would be mitigated if I ended up having to write SQL queries
>
> Correct.

I don't agree (if the above sentence means that having write SQL queries
will diminish the benefits of using Zope). SQL Methods greatly reduce
the gap between the RDMS and Zope. It doesn't magically objectify the
"relational" bits, but at least integrates them pretty well into the
Zope object space.

> It's likely that the part that stores data in the relational database
> might start out commercial, as well as the client-server version of
the
> object database.

This statement piques me, for several reasons. I don't mind that Digital
Creations publish products that are commercial and cost $, but I'd
object to any Microsoft-ish pricing (eg., if you'd sold Confera for
$1000 I'd definitely balk). So please be lenient, huh? But more than
that I'd like to ask you what happens when you demote a commercial
product to a free one. Isn't this unfair to all those people who might
have bought it?

Maybe you should consider stratifying your product line into "free" and
"subscription". If I join the Zope Gold Club for $500/year, I get all
your heavy-duty client/server stuff for free. Sort of a "fixed rate"
thing.

> > 	3) Zope is not "standard" enough that should I get run over by a
> > truck development could proceed without me.  Finding consultants and
> > programmers other than myself to work on this project could
> > be difficult.
>
> I completely realize that going with Zope is still a risky decision.
> However, the question of risk due to being non-standard is
> mostly offset
> by the risk of going with a closed-source vendor.  Do you
> _really_ trust
> Apple et al. to be responsive to all of your issues?  IMO, customers
> should demand control.

The risk from my own point of view is really that Zope's design suddenly
one day might prove inefficient. For example, what if Zope doesn't scale
beyond 1000 objects? That's my fear, because such a break in scalability
may be deep in its design. I doubt that Zope doesn't handle 1000
objects, because obviously you've done some testing beyond that limit
(you have, haven't you? Right? RIGHT? :), but since I've not looked
through all the sources I can never be sure that at some point I'll say
"I'd like to do..." and somebody will tell me "You can't, because
internally Zopes this and that as...". That's how Windows tends to work.
:-)

Alexander Staubo
mailto:alex@mop.no
http://www.mop.no/~alex/