[Zope] Help Needed - Case for Zope
sean.upton@uniontrib.com
sean.upton@uniontrib.com
Mon, 03 Mar 2003 10:45:53 -0800
Forgive the generality of this comment, but I think one of the biggest
things going for Zope is that it takes some hard integration problems and
makes them simple.
- ZEO makes object persistence cluster, and without really needing to do
much to your applications (other than have good conflict-handling code in
your applications to deal with increased storage write latency for the
network, and handling cache invalidation mechanisms). So for the most part,
clustered persistent objects allow things like shared sessioning across your
cluster to just work. Scaling becomes less of a development issue and more
of an integration/sysadmin issue, like it should be. I'll go out on a limb
to say that Java is going to make you work harder to not only get
close-to-transparent object persistence, but making that scale and cluster
will be harder, and certainly you will be tied down to one particular ODB or
serialization/storage framework vendor; ZODB is more open and more-or-less a
standard for Python folks. ZODB makes transactions easy too.
- Have you showed your management some of John Udell's latest InfoWorld
columns? ("Shipping the Prototype" and "Refactoring the Enterprise")?
http://www.infoworld.com/article/03/02/06/06stratdev_1.html
http://www.infoworld.com/article/03/02/13/07stratdev_1.html
- The Plone folks have plugged in their 1.0 press release that they support
the first "industry standard templating language" (paraphrase) in Zope Page
Templates. Since there are implementations of PT/TAL in other languages
now, you could argue that for the presentation layer, you get something
cleaner and more standardized than the popular (but platform specific) JSP
type solution.
- Make the case for Python; Zope naturally follows. One ROI factor for the
suits could be explained in terms of lower post-project "is done" expenses
(and therefore less risk), and that the language will enable your project to
be maintained without high-cost in the long term, which decreases (a) the
risk of scrapping the project 2 years down the line (because you can adapt
easier), and (b) the risk that you will need to spend big $$ on major
changes. Python lends itself to the "embrace change as inevitable" school
of thought, and gives you something easier to manage changes in the system
with. I think Udell's two articles go far to make this plug for "scripting
the enterprise." Plug Python's use for Star Wars at ILM, Google, etc. I
would also argue that Python makes it easier to write code in terms of your
application, rather than make your business fit your technology or spend
most of your time writing "bridge" code to make the two connect. See
http://www.python-in-business.org/success for case-study type blips as to
folks using Python.
- Scalability: plug ZODB's storage-agnosticism to your management folks.
You can use FileStorage, you can use BerkeleyDB storage, you can use
DirectoryStorage (which will scale quite well, has tools for incremental
backup and replication, and you can also use standard Unix tools too - works
quite well for high-availability clustering), etc. On top of various object
storage mechanisms, there is now a great mapping storage in
AdaptableStorage, which allows you to write plugins to serialize object data
to pretty much any mechanism you could think of (RDB, XML, LDAP, etc). This
flexibility (with mostly free, easily available, vendor-agnostic software)
is likely to be better and cheaper than what you might find in the Java
world, where these things are less standardized, and more vendor-specific.
Personally, I think the lower-costs, lower-risk, more flexibility arguments
go pretty far. Java, as a popular platform is a low-risk platform, but it
does this by moving the risk to the application (forcing you to deal with
object persistence or serialization, transactions, sessions, etc, choose
competing implementations of 3rd party technology - batteries not included)
and making the developer compensate to keep the risk low, but this makes
costs high. Zope, like Python has batteries included for a lot of things
that are traditionally application-developer's problems, and removes some of
the complexity away from having to do it yourself. Java's popularity, on
the other hand, encourages choice, but also forces it on you as well, by
playing to the hands of multiple vendors for app servers, object database
technology, etc. Zope's integrated nature makes it easier to get started
quickly without costly vendor or 3rd party technology commitments that may
turn out to be a poor match. Python is less popular, but decreases the
risks of your project, which ultimately is what really matters much more
than the platform. I hope this is somehow helpful.
Sean
-----Original Message-----
From: Samir Mishra [mailto:SamirMishra@cbuae.gov.ae]
Sent: Sunday, March 02, 2003 1:08 AM
To: 'zope@zope.org'
Subject: RE: [Zope] Help Needed - Case for Zope
Thanks everyone.
Any Project managers out there with something to add with regard to
comparison between speed of implementation for Zove vs. other products?
Personally, I place maintainability and transitioning skills as my top
priority, and elegance of code comes last. Speed (e.g., of the server) is a
non-issue because one can always allocate better hardware for this since
it's a mere commodity now, intellectual capital is always at a premium.
And that's why I like Zope :)
But I still have to sell the concept to managers who only hear "Java" &
"JSP" from software vendors and so are most familiar with these
technologies.
Samir.
-----Original Message-----
From: Paul Browning [mailto:paul.browning@bristol.ac.uk]
Sent: Sunday, March 02, 2003 11:58
To: 'zope@zope.org'
Cc: Samir Mishra
Subject: Re: [Zope] Help Needed - Case for Zope
--On 01 March 2003 21:52 +0100 Dieter Maurer <dieter@handshake.de> wrote:
> Samir Mishra wrote at 2003-3-1 14:26 +0400:
> > My manager has requested comments on whether Zope "performs like a
> dog". I'm > doing some digging around at the moment, but, in the
> meantime, if anyone has > any links to recommend, benchmarks,
> experiences to share, that I can use to > counter his 'assertion', it
> would be much appreciated.
>
One way of getting Zope "run like a bow-legged
terrier on sleeping pills" (Pieters, M., pers. comm.)
is to use multi-processor Solaris without paying attention
to the threading issues (see
<http://www.zope.org/Members/glpb/solaris>).
If you're starting from a clean sheet it's probably
best to avoid Solaris.
Paul
--
The Library, Tyndall Avenue, Univ. of Bristol, Bristol, BS8 1TJ, UK
E-mail: paul.browning@bristol.ac.uk URL: http://www.bris.ac.uk/
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )