[Zope] zope vs. siteserver from ms.siteserver newsgroup

[dale w lance]

--openmail-part-14ebac84-00000001
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.TXT"



> -----Original Message-----
> From: Brian [mailto:Brian@digicool.com]
> Sent: Wednesday, October 13, 1999 11:42 AM
> To: chris; zope
> Cc: Brian
> Subject: RE: [Zope] zope vs. siteserver from ms.siteserver newsgroup
> 
> 
> > Here's an exchange I had with a guy in the MS Site Server 
> > general Usenet
> > Newsgroup... can anyone find exception with his or my arguments?
> > Additionally, he doubts the ability of Zope to handle large 
> > sites (near the
> > end of the message).  Any clarifications are appreciated....
> > 
> 
> > > On the opposite, ZOPE is interpreted, not only the 
> > templates, even the
> > > server itself. No paradigm like COM is part of the game 
> > (though it might
> > > be extended). So ZOPE will be less speedy.
> 
> COM happens to work just fine with Zope :^) I've written a
> demo ExchangeFolder before that let you march into the
> Public Folders on your Exchange server as a little test too
> see if it would work. To me, the whole argument of "COM 
> components are compiled, so they'll be faster" is sort of 
> a lark anyway. 
> 
> If you wanted to, you could crank up your copy of VC++ and 
> crank out a COM component for your business logic. The fact
> that people don't seem to be doing this (or even clamoring 
> for info on how to do this) is telling. From the point
> of view of a web developer, the issue is not "gee, how many
> milliseconds faster can this COM component execute my query",
> its "how fast can we get this project done". Some people seem
> inexplicably not to have caught on to that yet :^)
> 
> 
> > > 
> > > Also: I really doubt the scalability of the ZOPE Object database,
> > > compared to the SQL Server that is part of the site server 
> > licensing.
> > > The ZOPE Object database - well - there are no benchmarks on it.
> 
> There are no benchmarks, true. It might be worth noting, though,
> that the actual backing storage of the object db is pluggable,
> documented and extensible. This architecture is specifically 
> designed to allow the use of alternate backing stores (oracle,
> other enterprise dbs, etc.) -- including SQL Server if you were
> so inclined.
> 
> 
> > > "When you do this, you're basically extending the Zope 
> > environment by
> > > creating your own object types without having to know a high-level
> > > programming language (ala C++/Visual Basic COM object 
> > development)." -
> > > well, just you do it in a slow interpredet language, where C++ COM
> > > Objects will be speedy!
> 
> Yep, speedy as hell - and a year late ;^) See above.
> 
> 
> > > "The power of this model is formidable.  For example, I 
> developed a
> > > "news item" object in 22 minutes which allows my users to 
> add "news
> > > items" to their department for perusal by other department 
> > members." -
> > > nive. What about adding 100.000 news items. What is the 
> performance
> > > then? This is unrealistic? OK, lets make an interface for a 
> > news server.
> > > 1 million messages a day. Youre dead.
> 
> This seems a simpleminded argument. If you are going to do
> something like a news server interface, you are also going
> to do the obvious design work beforehand that takes scale 
> risks into account. I believe he entirely missed the most 
> important points of your statement - "22 minutes", the 
> implied department-level scope of your solution, and the 
> fact that it worked for you.
> 
> The "youre dead" bit makes me wonder whether it's really worth
> much time bothering with this guy - you can't really answer
> someone who obviously already knows all the answers :^)
> 
<RANT>
I guess he also misses the point that every time the other operating 
system
(read MS) people come out with a new version it requires a much larger, 
more
powerful machine?
</RANT>
The idea is to make tools that get software to market faster and better.
Zope handles COM (see other replies). Zope interfaces to his database.
The only thing left is the Zope development paradigm vs his.

Of course this argument has gone on since the 60s and 70s. There has
been no luck convincing the other side, but here we are with bigger,
faster computers to run interpreted languages (among other things like
megalithic office productivity suites etc)

Dale Lance

--openmail-part-14ebac84-00000001--