[Zope] Zope vs. Enhydra
sean.upton@uniontrib.com
sean.upton@uniontrib.com
Sat, 30 Dec 2000 12:22:29 -0800
I agree that people should only build what they need. The nice thing about
Zope being open-source is that it evolves well to its communities use cases;
I would argue that Zope-based solutions would adapt to user communities that
are not a bunch of software engineers working for software companies. I
used to work as a developer for an R&D company and now work for a dot-com
doing the same sort of work, but my priorities are very different. Zope,
frankly, is a more pragmatic solution than committing to the Java platform
for a variety of problems faced by those of us not working for software
vendors, and I think is better suited to an open-source user community.
Two particular things:
One: Enhydra seems ideal if you have investment in the Java paradigm (i.e.
you have Java coders in house). The thing is that Zope has a lot of
strengths in the ODB that you can't get with your typical OO Java servelets
combined with an RDBMS back-end. For complex relational data, the Java app
server approach might make sense, but the thing that sells me on Zope is the
fact that their are problem domains that are a total misfit with a
relational data paradigm, like online content publishing (media sites),
intranet collaboration (workflow objects associated with discussions
associated with content created via content management) - not to mention the
entire problem domain of XML in general. So, java app servers make sense if
you meet all of the following criteria:
- have data structures that are tabular, or have a small
set of relations to other data
- have a full-time DBA
- have a full-time Testing Department
(test manager, testers) and Formal Software Testing
- have at least a senior Java programmer or two
- Have a fairly technical project manager that understands
how the app server works, in order to divide up work
- Fully implement formal documentation standards, including
UML, requirements & design docs, and EXTENSIVE API
documentation
- willingness to work on a deadline that is not as tight, putting
quality always before expediency
In other words, java app servers might make perfect sense for those working
in an R&D company, ISV, or other vendor selling software, but it creates
complexity when you want to extend this to an open development model because
the learning curve is steeper, and it's easier to screw something up. If
you work with limited resources, and are not building a product that is
going to have an expected sale value, but rather only internal use value
(i.e. you are a web company trying to get a site up versus a software
company selling a $25,000 shrink-wrapped box). When in that position, you
need content management built-in; you need portions (like the interface
layer) to be as easy as possible (Why should one be required to compile an
html file into a DOM binary - why not just use an ODB???); you also are not
going to have a testing department, you will have a stricter deadline, have
less technical project management, and no docs, and more employee retention
problems. The attitude is get it done, with the best possible balance of
doing it "right" and getting it up live. Zope fits the bill for most folks
who have to work in a pragmatic world of building and constantly refining
software for their own use. I'm not saying that we shouldn't have formal
docs, testing, etc of software, but that some of us have to maximize quality
under certain constraints that guarantee that the Java app server approach
would be flawed; Zope fits (python is easy to work with, the presentation
layer concepts in Zope are improving, etc). Zope also maps to open-source
ideas better, because it allows for a less centralized formal development
model, and the idea of constant refinement. In the future, especially in
certain vertical markets (like mine, publishing), the folks that comprise
your community will not be trained software engineers - they will be folks
like librarians, part-time web developers, designers, project managers, and
production engineers/sysadmins - and in that open source world, we need to
be able to create scalable software systems, but not raise the barriers to
entry to make them inhuman. Zope isn't perfect in this regard, but at least
it's leaps and bounds better than the alternatives.
Two: Perhaps the biggest gripe I have about the "why-not-zope" arguments is
simply that they make the assumption that Zope is somehow a product, and so
they complain about what it cannot do, rather than realize that zope's
primary asset is a strong community and a strong, swift software process; I
have seen Zope evolve quite rapidly over the last year-and-a-half; I use
that as empirical evidence that Zope grows with its community member's
use-cases. Gripes about things like through the web editing, cvs, etc will
likely be things of the past in the not too distant future.
I think Zope has some advantages over both other approaches in that it has
an approach that targets a different set of uses. While we can argue about
Zope's fitness being a "general-purpose" app server, but when it fits the
needs of its users, or adapts in order to do so, what's the point?
Sean
-----Original Message-----
From: Terrel H. Shumway [mailto:tshumway@octavian.ICS.UCI.EDU]
Sent: Friday, December 29, 2000 11:10 PM
To: corey@axcelerant.com
Cc: zope@zope.org; tshumway@octavian.ICS.UCI.EDU
Subject: Re: [Zope] Zope vs. Enhydra
Flame bait? Catch this:
I have recently been reaching the disillusionment phase with Zope, so please
take it all with several grains of salt.
I happened upon an article in the ArsDigital Systems Journal that I thought
was a fairly neutral review of Enhydra.
http://www.arsdigita.com/asj/enhydra/index.adp
The more thought-provoking part of the article was a reference to a fairly
disparaging view of application servers in general.
http://www.arsdigita.com/asj/application-servers
What got me to ArsDigita was AMK's Zope frustrations.
http://www.amk.ca/python/writing/why-not-zope.html
(BTW, some of these issuses are being addressed.)
Which also lead me to Chuck Esterbrook's musings
http://pywx.idyll.org/advocacy/why-not-zope.html
http://pywx.idyll.org/advocacy/why-not-zope-2.html
Chuck Esterbrook created webware as his answer to Zope's limitations and
complexity. http://webware.sourceforge.net/
Titus Brown advocates use AOLserver and Python (instead of TCL)
http://pywx.idyll.org/advocacy/
IBM developerworks has a couple of Enhydra articles (which I have not read
yet)
http://www-106.ibm.com/developerworks/library/enhydra.html
http://www-106.ibm.com/developerworks/library/w-friend.html?dwzone=web
In summary: Don't build what you don't need -- do the simplest thing that
could
possibly work. Evaluate potential solutions in terms of business value to
YOUR customers, not in terms of market hype.
HTH
-- Terrel Shumway
_______________________________________________
Zope maillist - Zope@zope.org
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )