pcplantdb

[Chad Knepp <pyg@galatea.org>]

Richard Morris writes:
 > Chad Knepp wrote:
 > > Hi all,
 > > 
 > > Kinda wondering why I'm so quite aren't ya?  Well, I unexpectedly
 > > acquired 15 ducklings (arrived a month early) and I've been jumping to
 > > get them settled.  It's mostly gone ok so far.  Anyway, I have a
 > > couple of loose ends to tie up and then I will get back to work for
 > > real although I have to check in on the ducklings every 3 hours or so
 > > minimum.  
 > > 
 > > I've been reviewing the code and think that my next move will be code
 > > clean up 
 > 
 > Sounds good. Did you spot the issue about a name clash as windows is 
 > case dense.

No, haven't looked at the tracker recently...

 >  > and splitting it into client and server packages, droping the
 > > text client, and also mostly dropping xml as the transport language
 > > between html client and server.  The server will however implement
 > > xml-rpc to serve other clients.  My reasoning is that I can see no
 > > good reason for the server to mark up anything (other than xml-rpc)
 > > and it is not helpful for the client to mark up the data as kfml and
 > > then convert it to html.  Some data in the database itself will be
 > > marked up as kfml which is then the clients responsibility to convert
 > > to an appropriate internal format.
 > 
 > We'll need to cordinate with Bear on this
 > 
 > issue11
 > > I'm ready to improve the layout, but I need a few changes made (by Chad) 
 > > in 
 > > (KHTML?) first.
 > > My suggestions:
 > > all results wrapped in <div id="results">
 > > each results wrapped in <div class="result">
 > > family/species links get classes: <a class="family href="...">
 > > the text/description gets a div with a class...<div class="text (or 
 > > description)">

This is very high on my list of important things to do.  Expect it
within two weeks.

 > > One of the big reasons for the code clean up and split is that I've
 > > been getting irritated by some of the implementation choices I made
 > > early on that just don't scale that well.  When what we were doing was
 > > very simple everything worked well, but most of Eden/Session.py has
 > > gotten pretty kludgey as a result of adding more features, dealing
 > > with cookies (a client issue anyway), etc.  I don't want to add
 > > anymore features (like relationships) and then have to redo even more
 > > later.  This will also facilitate other folks working on the client
 > > (Bear expressed some interest).
 > 
 > Indeed, this is well worth the time. A solid framework will be well 
 > worth the effort. A bit concerned that we haven't really sorted out
 > meta-schema questions. So it may prove a bit tricky making sure that
 > the framework will meet all the needs.
 > 
 > Maybe we should discuss this a bit more.
 > 
 > > 
 > > The server will be very small and have a limited number of methods
 > > including basic data input/output, searchs, authentication, and
 > > verifying data correctness.  This should result in a well documented
 > > API that is easy to work with.
 > 
 > Cool. Documentation for API would be a great thing to acheive.
 > Drawing a clean line between server and client is good.

In python (and Java) good internal documentation results in a good
external documentation via pydoc/happy/etc.

 > > Another kind of technical point is that the html client will be
 > > closely coupled with the server because it can.  It will import the
 > > server and utilize it like a library/package.  Other clients could do
 > > this as well, but most remote clients using a centralized database
 > > would need to use xml-rpc.
 > 
 > Need to work out quite what client will produce. Will it be html/xml. I 
 > know Bear was thinking of using xslt to transform xml to html which 
 > might be the easiest way to make output configurable, and giving us the 
 > posibility of using diferent trasforms to tweek the output.

I'm not really attached to what the client does but I'm drawing a line
at how much work the server puts into formating/markup.  IMO, this is
the clients responsibility, because clients could differ greatly here.
A text client might not need much formating at all.  Not knowing
anything about xslt I'm not all that eager to implement it...

 > I've got quite into the idea of using microformats to add some semantics 
 > to the output. Basically this consists of adding class="tag" atributes
 > in appropriate places. A semantic xml layer would help greatly with this.

I must be tired, this just doesn't sound that interesting to me ;-)

 > > Anyway, to summarize, my next self appointed task is housekeeping
 > > which I expect to take about 2 days and I expect to have completed
 > > within a week from now.  After than I will start tackling my issues
 > > (the tracker sort, not emotional/psychological ;-).  Believe me,
 > > cleaner code will make everyone happy.
 > 
 > Its also work checking the spec docs on the wiki

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