pcplantdb

[Chad Knepp <pyg@galatea.org>]

John Schinnerer writes:
 > Aloha again,
 > 
 > A quick "ditto" to Chad's comments, and I will add some further
 > thoughts here:
 > 
 > > Althought this may seem like quite a jump, another way to create
 > > a framework of collaboration is the a distributed peer-to-peer
 > > network....

 > > The cons are primarily around creating something so large and
 > > complex that it is a barrier to entry.  The web is easy to use
 > > for almost everyone and I can't see a way to make some of the
 > > aspects of a distributed peer-to-peer network as brainless as the
 > > rest of the web.
 > 
 > I am still strongly thinking that an object DB is a way better
 > match for what we want to do than an RDBMS.  Plants have attributes
 > and methods - at least I can conceptualize this better that way
 > than the tables and rows and stuff.  A plant is an object.
 > The attributes encode/express plant qualities, functions,
 > relations, etc.  The methods enable manipulation (add, modify,
 > delete, share, sort, query, etc.) of the attributes.
 > This seems even more appropriate if thinking of the peer-to-peer
 > sort of system.  A pretty simple web UI would let people
 > create/modify/etc. plant objects and object relations,
 > etc. (subject to the graffiti/moderation controls of course).

Yeah, I can see how an object DB would tie in neatly with an object
method of peer to peer data exchange.  I'm not opposed to the idea and
I'm totaly into the OO methodology, but I really don't know anything
about object DBs.  Does zope have an object DB backend?  Sell me more
on object DBs.  What should I be reading/looking at?  I also have some
concerns that may just be questions if I look into it more (like
performance). 

 > > Somehow the XML format seems to be the core of the project. I'm
 > > presuming that this will be the primary format between client and
 > > server. With that in place different api's will be possible.
 > 
 > Only drawback I know of is overhead (who was it said that quote,
 > something like "XML is the least efficient way yet developed to
 > move data around"...?).  Other than that, it's about de rigeur
 > these days to XMLize everything.
 > 
 > There can be "thin" clients where all that processing is done
 > server-side, no?  So that can help with the overhead issue for
 > low-bandwidth connections.

I personally think XML is just the latest in a long list of useful but
tremendously over-hyped technologies.  I don't think there is even
that much to it as a technology.  But again, it does make sense for
some things, esp. where you have to translate data into a number of
different forms.  I did choose to use it in Eden because I figured I
could support the most front ends that way and as proof of concept
wrote a CLI/text and web based front end (toot toot).  It's also quite
possible to optimize anything and in Eden every unique search
generates a cached page of text or html that repeated searches
retrieve in about 20 lines of code and one sql query (toot toot toot).
I didn't do that because the xml -> html/text was so slow but because
the search engine itself is kind of a pig.  It's also true that xml ->
html/text in Eden is a complete kludge and that as the dtd developed
the xml part may be a preformance issue as well.  Um that tooting was
my *own* horn ;-)

This may sound odd, but I really don't feel that comfortable calling
and talking to Jim.  I'm hoping you all can relay some of my
enthusiasm, and that we do have ideas on where to do this project.  I
would be disappointed if we didn't get funded because he concluded
that we didn't have it together technically enough to make it happen.

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