Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] duck emergency

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] duck emergency
  • Date: Fri, 10 Jun 2005 21:02:34 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page