pcplantdb

[Richard Morris <webmaster@pfaf.org>]

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.

> 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)">

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