pcplantdb

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

Aloha,

>  > If you really are not willing to talk with him in person at all, I
>  > want to know why not, mainly because I want to know more about you
>  > if we are to be working on this together.
>
> This is mostly a personal oddity of mine and part of my geek heritage.
> I choose not to use phones very much.  I feel uncomfortable talking to
> people I can't see because the emotional subtext of the conversation
> is only available in intonation which is very confusing for me...
> My fear is
> that I will not be able to think clearly enough quickly enough to make
> a positive impression.

Thanks for your very frank and clear answer to my question, Chad.  I hear you,
and of course IMO it's up to you as to talking to Jim by phone yourself or
not.

My take on Jim relevant to your fear above is that he's not a person who
requires a quick and concise answer to all his questions from all of us in
order to have a positive impression or support this project.  I gave him some
long digressions and he seemed happy enougth with them...! I think partly he'd
like to talk to more of us relatively few active folks because at present
there *are* relatively few of us.

So given your and my comments above and anyone else's comments that might
apply, whatever you choose re talking with Jim is OK with me.

>  > His main concern is how will we in practical terms dive in and
>  > proceed if he gets us some money.  The likely amount he mentioned
>  > coming through in July was in the $12k - $20k range, if it does.
>  > What could we do with that, he wants to know.  He likes what we are
>  > about as he's heard it thus far.
>
> This seems like it would have a pretty significant impact on the
> project.  I think everyone should have a weigh in about how this new
> budget would/could affect their participation in the project.

I will put some cipherin' on my to-do list and make some kind of estimate of
time/money for getting basic QA stuff mentioned in previous post in place. 
Don't think it will take too much - biggest task I see right now would be
evaluation of issue trackers in order to pick a good one.
If anyone has positive and/or negative experiences with open-source issue
trackers (a.k.a. 'bug databases', though we don't want something that can
*only* handle "bugs" as a good issue tracker is a good overall project tool),
please shout 'em out.

> My original thinking is that even though it was billed as a half-time
> job it would actually make more sense to work full time until much of
> the coding bit was done and then refine/maintain as authoring began.

Agreed.

> After the design considerations are finalized it seems like not much
> else can happen until we have some alpha level product to start
> playing with.

Agreed - though I think 'finalized' is a bit of a strong word... :-)
How about something like 'intial design considerations and parameters are
agreed upon'?

> It's my opinion that maybe authoring should be postponed at this phase
> of the project until more financing becomes available.  It is also my
> own belief that we will get the best/most content by creating a tool
> that solicits it from the general public and not by trying to do it in
> house.  I think it makes the most sense to focus this initial funding
> on design and development.

Agreed - with the caveat that we need some "real" and realistic data to use in
design/development.  How might we get some?

> I think I'm starting to visualize where you are going here.  I need to
> study up on object DBs, but I think I'm on board.

My simplest understanding of object DBs is that the provide persistence for
otherwise non-persistent objects.  ZODB for example provides fairly
sophisticated (transactional, scalable) persistence for objects coded in
python.

> I also don't think
> that what you are talking about is going to be a big climb for you
> based on what you are able to conceptualize.

The conceptualizing is the easier part for me.
The 'climb' is about wrestling with the ultimate particulars of a specific
language and syntax, spending hours trying to suss out why one or two bloody
lines of code won't do for my specific situation what they supposedly do in
some general example, waiting perhaps days for a listserv answer to a question
that is insanely trivial once I have the answer and insanely unfathomable
before I have the answer...that sort of stuff!

> A pure object approach
> has an appealing clean feel to it.  I can imagine being able to do
> really nifty things like being able to attach a discussion object to
> any object.

Yes! You're ahead of me with that one, too, but that's the sort of stuff
behind me advocating an OO approach.  Imagine ataching a guild relation object
too, and so on...

> I suppose these are relational indexs of the objects.

Not sure...B-trees are involved I'm pretty sure, I don't grok it all, haven't
looked into the guts of it much.

> My initial
> performance concern was based on how you would look through data
> elements of every object quickly.

Doc/info on Catalog code optimization in more recent versions, by the coder
himself:

http://zope.org/Members/Caseman/ZCatalog_for_2.6.1/view

> It would be really nice to have the "full text search" capabilities of
> RDBMS.  How do you index "narrative" data in an object DB?  Maybe
> ZODB/ZCatalog has this

Indeed it does - built-in - and there are some plug-in products that enhance
the basic full-text capabilities.  Can even have custom vocabularies...which I
don't grok yet but sounds useful for the right situations.

Here's a howto/tutorial on ZCatalog:

http://www.zope.org/Documentation/How-To/ZCatalogTutorial

NOTE:
* Ignore the archaic and messy HTML-munging markup in some of the examples -
not relevant to our situation
* At the end it points out that ZCatalog is just a zope wrapper for the
Catalog module, which can be used outside zope using ZODB as object DB.

So for those who may have issues with zope as a whole, none of what I am
talking about depends on zope per se.

A simple example of the full-text search can be played with here, in the
caption text search of this simple gallery:

http://www.sfkingsriver.org/gallery/

Mind you this whole search, including the full-text part, took pathetically
little effort on my part.  Gallery items are objects with attributes such as
date, photographer, caption, etc. that get put in a ZCatalog...all I had to do
was specify caption as a text index in the relevant catalog and plug in the
right (&*&$&!!@%$#&**%$!) syntax in a few lines of search code and bingo -
instant full-text search of all caption attributes in all cataloged gallery
items.

> Another thing I've been thinking about which only really differs in
> implementation is that we could use an RDBMS as the *catalog* and
> create our objects as stored procedures within the RDBMS.  MySQL just
> got stored procedures in 4.x something and I think postgresql has had
> them for a while.

If I understand correctly I reckon that would work.  From what relatively
little I know about the guts of them all, python and ZODB would be much easier
in the long (and maybe short) run...?

> Mostly I like and qualification could be determined by achieving
> certain level of communty-reputation as per your next paragraph.
> Getting moderation right is going to take some effort and none of it
> is totally clear to me right yet.

Yes, I think we have some experimenting to do there, and Jim may have some
more good ideas from his social-systems perspective...



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