pcplantdb

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

Aloha,

Another brief burst of bandwidth in my travels...catching up...

> I've a fair range of hardcore dev chops too!

No offense intended Rich, I gathered you did.  Also seemed like you and Chad
had some common and some not at all common chops - maybe we could have a quick
reprise from both of you?

> This seems to be about the figure I was expecting,
> much less than the original proposal,...
> I guess this would encourage us towards a Keep it Simple
> Stupid (KISS) development model.

With a few moments' thought, my goals for this phase as head test curmudgeon
would be to get basic QA infrastructure in place and provide some basic
testing docs and "mentoring on demand" so we get quality QA from the start.
Infrastructure would basically be getting an issue tracker (a.k.a. 'bug
database') up and going for the project and available to all interested
parties.
Basic testing docs would be a howto on writing a bug or other issue, FAQ on
basic testing processes, other...???

> And the format of data returned by API calls (i.e. XML format)
> is really part of the API.

Yeah, would be, wouldn't it?  So the XML we use needs to be well-designed.

> I've no real problems with an object based approach,
> apart from never having played with it. I'm not
> really sure on the advantages though; compare a
> plant object
>       class Plant {
>               String LatinName;
>               String CommonName;
>               ...
>       }
>
> To a typical RDBS table
>
> Table Plant
>       Field LatinName
>       Field CommonName
>       ....

Add some methods to your class Plant, that's the big difference.
The plant object would have methods as well as attributes - it would be more
'self-contained' for manipulating and expressing its own properties and/or
querying the properties of other plant objects, and thus IMO much more like an
actual plant.

Subclassing seems a very powerful way to build complexity in our DB system
without manually replicating code or re-coding unnecessarily.  We can start
with relatively simple and general plant objects and then subclass them and
add complexity - getting all the structure and code of the more basic objects
'for free'.

An RDBS table is just data *about* plants...all the code to manipulate the
data is 'external', not integrated with the info that constitutes the plant
properties.  Really it's the thought of ever-increasing complexity of tables
and  SQL queries that makes my head hurt...

I'm sure it *could* be done either way; the object way just feels much more
integrated and intuitive to me. I don't have huge practical experience with
either approach so I think I'm not too outrageously biased...

I would guess that most all current plant DBs are RDBMS based...?
For me that's a reason to go object-DB right there - otherwise it seems we
might find something existing in the open-source RDBMS/SQL world and just
modify it to suit our particular PC-centric needs instead of starting from
scratch.

> The one question I would have is if some binary format
> object would be passed between front-end / backend.

I was assuming not, since that wouldn't be very 'open' it seems to me (if I
understand what you mean by binary format object).

> To my mind text formats have a lot of advantages here:
>       1) Their intrinsically more open, you just
>               need to look at the data.

Yep.

> Which format
> would you perfere to work with HTML or
> Word?

Absolutely not Word, it's proprietary and commercial.  Sure, it's 'published'
and all that, but it's still not "free" as in open source.  It's also a mess
IMO.
I was assuming we were reaching consensus on XML for data exchange, or are you
talking at a different level than I'm thinking?

>       2) They might make things harder for clients
>               any client in any language can parse
>               XML or other text format. But will
>               MyFavoriteLanguage be able to interpret
>               objects created in YourFavoriteLanguage?

Exactly - again I'm assuming no proprietary binary stuff for data xfer.
What comes out of the back end is XML, that works for me and hopefully lots of
other people.

>> Again, if this is built carefully the guild aspect will be both implicit 
>> and
>> an emergent property.  Some added logic to extract and/or extrapolate guild
>> information from plant objects and voila!  Stephanie's dream realized!  ;-)
>>
> Brain too small to understand this! Please expand.

How do you parse that - expand your brain, or expand on my cryptic comments?
I'll take a wild guess at the latter... ;-)

Hmmm...OK, this is based on object-oriented DB first of all...we've got these
plant objects with their attributes, which could include guild-relevant
attributes as well as 'general' attributes that might point to guild
possibilities, guild relationships.  That's all built into the objects.  Also
built in are methods to manipulate, expose, query these attributes.

So, asking the right questions of the objects (e.g. the right 'search' on the
object DB) will result in guild-relevant results.  That's the general thought.

Again I am sure similar results could be achieved with RDB/SQL but the model
seems less a match with actual plant objects and their relations than the
object model does...to me anyhow.

An instance of a plant class not only creates a persistent new plant object
with particular plant attributes; that plant object can also be asked about
itself and supply answers via its methods.  For me this is much easier to
model and visualize than creating rows in tables and queries on those tables
that somehow represent a plant and its answers to questions about itself.

> I doubt we'ed see a need for multiple servers in the short term.
> (Different mirrors of same data maybe?)

Jim did mention mirrors as something that would at some point be nice to be
able to have.

> For simple things its as good as any other text based format.
> It can get really hairy when you start looking at
> XPath, XLink, XML Schema, namespaces etc. etc. When you
> get too involved in all the fancy bits it looses its
> simplicity and the markup to data ratio goes sky high.

That's my only concern.  I am guessing that we could avoid that happening...?

> What I'm doing for modoration of reader comments to PFAF DB
> is that I get emailed a copy of every comment submitted.
> It should be quite easy to do have a accept/reject email response.
>
> To my mind such a system is all we'll really need for version
> 0.1. The rate of submissions will probably start small
> (aprox 1 comment a day), so the workload will not be too hard.

Agreed to start with...and make sure we design for managing higher inflow of
data from the start so we don't end up having to hack that in somehow later
on.

Basic workflow stuff from content management models - submit -> review ->
[publish | return for editing and resubmission | reject | etc.].



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