pcplantdb

[John Schinnerer <john@eco-living.net>]

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