pcplantdb

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

Aloha,

Well done Chad, couple comments...

> Hmmm... sounds like something GBI is necessary.

That was Stephanie's original excitement for a front-end...ThinkMap...John
Howe and I poked around for open source stuff and came up with TouchGraph
looking like the most stable/mature GBI in that realm.  That was a while
back, don't know if that's still the case...?

> The only way that my vision differs much the above is that you seem to
specify that a GBI is an optimal way to represent/understand/create
guilds and I don't know that I agree with that.

IMO it will be useful/optimal for some; other GUIs will be more
useful/optimal for others.  My understanding is that we dealt with this in
basic design by deciding we will have a nice clean API to provide
server-client separation and multiple opportunities for front ends, one or
more of which may sooner or later be a GBI.

> I also think we can do graphing stuff pretty easy esp. if it is keyed to
similarities or differences in attributes.  As an example, let's say
that you have a plant and you want to explore other plants that are
similar in height, shade tolerance, moisture requirements, etc. This
would be a good way to find replacement/alternatives for
> particular guild members.  Anyway, I think would be trivially easily to
write the server elements if Richard wants to play with TouchGraph.

I agree, it should be pretty easy with well-designed objects and
ZODB/Zcatalog behind it.

> Chad's Plan.
>
> Here are what I see as the core elements of HG that I propose to
implement....
>
> 1. Database creation with basic search and minimal web interface.
>...It's
>   not at all important to get this absolutely correct up front, but
changes later on will have to be in both client and server elements.
This is to be expected and won't be that difficult.

I agree that the attributes will evolve to some optimal set as we go and
that to try and figure them all out first is both not possible and poor
design practice.  Big risk of "analysis paralysis."

>   Proposed implementation: Python using ZODB and Zcatalog running as a
python cgi from a webserver...

>   The search function will also be a minimal function unless people want
something smarter.  Tooting my own horn again... Eden has a very
sophisticated search engine.

How much have you looked at ZODB and ZCatalog so far?  Pretty
sophisticated indexing and serach abilities built in, plus there are some
mixins (products) to enhance ZCatalog searches.  IMO anyhow, having only
played with the rudimentary stuff so far myself.

>   ...Proposed implementation: Adding user objects and authentication,

User objects and roles, authentication and permissions are built into
Zope.  If Zope is the application server (behind Apache for management
reasons - what say you, John H.?) this is trivial, no need to code it
(other than additions/customizations if we need them).
Built-in roles include Anonymous, Authenticated, Manager and Owner. 
Arbitrary new user-defined roles can be added.  Every object has a
roles/permissions matrix that allows from broad to fine control of
access/permissions, and inheritance takes care of permissions for objects
one doesn't want/need to mess with individually.

Also Zope as application server already integrates ZODB and ZCatalog - no
need to go to them separately via cgi.  If we get big there's ZEO, zope
enterprise objects, which provides transparent scaling of the object DB
across multiple servers, etc.
As with most decent web app servers, zope can return whatever the heck we
want it to, from vanilla html to XML or whatever.  Some of that is built
in, some available as products, some would be custom stuff.  Can hook into
external SQL DBs too if we want at some point.

>   adding edit tracking capabilities,

This (or much of it) might already available from various zope products. 
CMF (content mgmt. framework for Zope) and Plone (a CMS built on Zope, see
plone.org) both have workflow stuff that might cover some or all of this.

> 4. Moderation and reputation system.
...
>   Proposed implementation: a peer reputation weighted information
moderation system to indicate information relevancy/validity.
>
>   Notes: Absolute guess about time.  We need to talk more about this,
but I really like what John reported of his conversation with Jim F.
about a community reputation system of moderation.

Snipped the quote, and, I still like the ideas therein myself as well. 
Seems a very good start anyhow.

> P.S.  Good to still have you alive John, sounds like it was close!

Thanks, the consequences of a smack like that are unpredictable and I came
through with a relatively mellow set of them.  Alas not my car...

cheers,
John S.


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