pcplantdb

[Chad Knepp <pyg@galatea.org>]

John Schinnerer writes:
 > <snip>
 > > 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."

Yep.  I've flexed the PFAF/Eden dataset around a lot adding and removing
attributes and I'm still not happy with it.  I suspect HG will go
about the same.

 > >   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.

Not yet.  Zope fun is my planned pre August 1st. activity.  I'm going
to make a little personal accounting/budgeting program to get the hang
of things.

I'm not sure what sort built in features Zope has, but most of the
sophistication in the Eden search engine was not SQL based or part of
builtins.  I did a lot of research on search engine design; more
specifically, intranets because of their more specialized data...  I
could blab on forever about this stuff but I idealize google as my
user interface.  I can type just about anything into a single text box
and even spell wrong yet Eden gives me something interesting.

 > >   ...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.

Sounds great!  My time estimates for 3+ where assuming that I would
write it all from scratch.  Hopefully, it seems, this won't need to happen.

 > 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.

Will look into it.  We need edit tracking for objects though, not just
text blobs.  I've got a lot of Zopeing up to do in the next
week... maybe it'll make me smell better ;-)

 > > 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.

We may be able to borrow some code from squishdot like system if it
seems worth the effort of incorporating.  The high time estimate was
assuming this wouldn't happen.

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'