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/