Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] platform revisited

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: John Schinnerer <john@eco-living.net>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: Re: [pcplantdb] platform revisited
  • Date: Wed, 11 Aug 2004 23:58:05 +0000

Aloha,

Thanks Chad, well done summary IMO - and I say that because basically I agree with your technical analysis below.

So that's whaddIthink about that.

John S.

Chad Knepp wrote:
Ok, let's start over.

Zope pros:

o Robust development platform with many features built in allowing
rapid development and the capability to add features in the
future.

o OO model throughout allowing clean coherent code easy to read,
maintain, and extend.

Zope cons:

o Not supported currently by our prefered ISP (ibiblio). If we
choose to not go with ibiblio we would loose support from
Lawrence.
RDBMS pros:

o Good performance.

o Runs on ibiblio.

RDBMS cons:

o Awkward development model.

o Have to write everything from scratch.

Some ideas:

1) Use Zope and 'damn the torpedoes'. Start on arashi and move to
ibiblio when they get a Zope server running or buy space at
johncompanies or some such if ibiblio doesn't.

2) Use python with a ZODB backend as well as some Zope tools (like
Interface and Catalog) on ibiblio.

3) Use Eden but abstract the database interface so that we can
[hopefully] forward port to Zope in the future. This would also
be RDBMS agnostic allowing use of PostgreSQL, Firebird, MySQL,
Oracle, DB2, etc. interchangeably.

4) Use Eden/MySQL and 'damn the torpedoes'. Continue development
from the existing codebase.


My take:

1) From a technical perspective I think this is the best choice.
From a political perspective if Lawrence leaves the project based
on this choice it would definitely create a hole. Lawrence, do
you think you would consider shifting on this issue some?
Features/Time = Fastest.

2) Second best from a technical perspective. Shouldn't be too hard
to forward port to Zope in the future. In the meantime it means
we have to write all the Zope utilities and features
ourself... although we may be able to use some of the other
Packages in a stand-alone way like ZODB. Features/Time = Slowest

3) You guessed it, third best from a technical standpoint. This
would promote the most thorough OO model possible in a non-Zope
environment... although no persistent objects (*sniff*,
*whine*). Features/Time = Third

4) This one blows rocks technically, but second to 1) would result
in the fastest development. Features/Time = Second

Waddyallthank?


--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net




Archive powered by MHonArc 2.6.24.

Top of Page