[Zope] ArsDigita .. request for comments

[Jimmie Houchin]

"Andrew M. Kuchling" wrote:
> 
> Jimmie Houchin writes:
> >So to scale with Philip you develop with AOLserver/Tcl/ACS, buy big,
> >expensive hardware, buy big expensive database. ie: throw lots of money.
> 
> Actually, that isn't quite the point.  He isn't actually arguing
> for AOLserver's superiority over every other system, and somewhere
> (but I can't find exactly where) he suggests instead:
>
>      Your development technology doesn't matter.

This is true, he doesn't necessarily argue for the superiority of
AOLserver vs. the world, and that is not what I said either. However, he
strongly advocates for AOLserver, which is fine it is good work. But he
and others who follow have also advocated against extending AOLserver
for tools other than Tcl/ACS. He says, after all, what for?

Jimmie>> Start off with a highly scalable, multi-threaded, high quality
webserver
Jimmie>> with an embedded scripting interpreter. In his case AOLserver
with Tcl.

> I wish more managers knew this.  You can build interesting
> applications in Zope.  You can build them using Java servlets, or CGI,
> or WebObjects.  No tool is going to magically solve all your problems,
> and solving them will require familiarity with your tools, hard work
> and careful effort, no matter what you use.

This is true, but it isn't wrong to want to do your job with a tool you
enjoy. In the event that there are multiple qualifying ways of doing a
job within reasonable means of quality, I think a tool you like and
enjoy would potentially help and enable productivity. There is not
necessarily any magically programming language or tool. However, some
are better than others. Programming well, requires effort and work.

> We had a manager here who was quite enamored of Java, and early on we
> wrote some stuff in Java servlets.  He viewed our Zope work as just
> stopgaps on the way to Java code that would carry us into the
> long-term, but every time I asked "What problem would be solved by
> rewriting all our Python code into Java?", there was no clear answer.
> Unfortunately, far too many people in business computing follow
> a similar management-by-white-paper-and-press-release style.
> 
> Similarly, Greenspun argues that you shouldn't re-invent databases; it
> would require a tremendous amount of work to add to your home-grown
> system all the features that existing databases have -- fancy query
> optimization; storage across several devices; on-line backups;
> federated operation; etc...  So use an existing system; Greenspun's
> preference is Oracle, but he doesn't argue it like a law of nature.

Because something requires effort, even tremendous effort doesn't mean
it isn't worth it. Because something may duplicate features of another
product doesn't mean it isn't worth it. Linux did all of this.
Tremendous work and effort to somewhat duplicate available software. At
some point the efforts which could be perceived as a duplication of
existing software may at some point supplant and exceed the currently
available existing systems. Subsequent versions of many existing
software packages can also fall into this same description of tremendous
effort, to duplicate the features of existing software. But this is
generally for a reason. Some times to improve certain things,
performance, add features, interoperability, portability, etc. I'm sure
Oracle has done this. I'm sure Philip has.

In his forum and other writings Philip has openly argued against most
any potential competing database to Oracle. In his argument he believe
the price of Oracle isn't/shouldn't be a problem. However, to many
people it is. Even though his webserver of choice is db agnostic, his
software ACS isn't. It is very much hardwired to Oracle. Talk to the
people involved in the ACS port to PostgreSQL.

Any advancement of technology will come at a price of tremendous effort
and duplication of current capabilities and features. Sometime it's
worth it, sometimes not.

Philip is right on many of his points. How much has software really
advanced from the capabilities in Lisp from so many years ago? Very
debatable.

As I said his book is a very good read, great material. I like many of
the business ideas and practices of ArsDigita. I have populated my
library with many of his book suggestions.

I have absolutely nothing against Philip, ArsDigita, AOLserver, ACS,
Tcl, etc. AOLserver/ACS is a great tool and toolset. However, in the
discussion of comparing AOLserver/ACS (really ACS) to Zope it basically
boils down not as much to features but to design/architecture of each
tool and scalability. Some people will prefer the ACS way over the very
OO way of Zope, some the opposite. If you are agnostic on such, then
scalability may become an issue. AOLserver/ACS and Zope scale
differently. Philip has a distinct view scalability. Farms, clusters,
no. Single machine, multi-processor, yes. Database == Oracle (his other
uses were also big $$$dollars). Hence scalability == $$$dollars.

AOLserver/ACS currently scales better than Zope. Zope may not currently
be the best choice, or a choice, for Amazon, Ebay, etc. But I think it
can someday. Because Zope is reasonably db agnostic (it does like
transactions), it may be a better solution for many people than ACS
since it is tightly linked to Oracle. If your money and data is
somewhere else you would have to port. In their forum I made comments
that it would be great if ACS were decoupled from it's specific database
dependency. The db connectivity could be abstracted and an appropriate
database api could be created. This would enable other database users to
use ACS. No interest from ArsDigita. Instead there are various peoples
rewriting ACS for their db of choice. As far as I know all hardwired. :(

There is definitely room for both to be successful, and others like
Enhydra. Then there would quality choices for users of various
backgrounds and personal preferences.

There is most definitely a give and take among the choices out there for
languages, webservers, app servers, etc. As for me, when surveying the
landscape from my world view and perspective, the other options
primarily potentially beat Zope "currently" in scalability/performance.
But for me Zope won other areas. I like Zope, I like ZODB. If I don't
have to use an RDBMS, I won't. However, I do hope for ZODB to improve to
the robustness and scalability of the RDBMSes. For some uses it is.

As I read the paper today and see 1 ghz Athlon machines becoming
available, Zope horizons are looking better. Go Moore go. :)

Jimmie Houchin

> --
> A.M. Kuchling                   http://starship.python.net/crew/amk/
> One has no wish to be devoured by alien monstrosities, even in the cause of
> political progress.
>     -- One of the Tribunal, in "Carnival of Monsters"