Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] duck emergency

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: pcplantdb <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] duck emergency
  • Date: Fri, 10 Jun 2005 19:04:59 +0100

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





Archive powered by MHonArc 2.6.24.

Top of Page