pcplantdb@lists.ibiblio.org
Subject: pcplantdb
List archive
- From: Chad Knepp <pyg@galatea.org>
- To: pcplantdb@lists.ibiblio.org
- Subject: [pcplantdb] duck emergency
- Date: Fri, 10 Jun 2005 11:32:59 -0500
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 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.
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).
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.
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.
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.
Cheers,
Chad
--
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'
-
[pcplantdb] duck emergency,
Chad Knepp, 06/10/2005
-
Re: [pcplantdb] duck emergency,
Richard Morris, 06/10/2005
-
Re: [pcplantdb] duck emergency,
Chad Knepp, 06/10/2005
- [pcplantdb] Client, server, XML, HTML..., John Schinnerer, 06/11/2005
-
Re: [pcplantdb] duck emergency,
Chad Knepp, 06/10/2005
-
[pcplantdb] server-client split,
John Schinnerer, 06/11/2005
-
[pcplantdb] server-client split,
Chad Knepp, 06/15/2005
-
Re: [pcplantdb] server-client split,
Richard Morris, 06/16/2005
-
Re: [pcplantdb] server-client split,
Chad Knepp, 06/16/2005
-
Re: [pcplantdb] server-client split,
John Schinnerer, 06/16/2005
-
Re: [pcplantdb] server-client split,
Chad Knepp, 06/16/2005
- Re: [pcplantdb] server-client split, Sean Maley, 06/17/2005
-
Re: [pcplantdb] server-client split,
Chad Knepp, 06/16/2005
-
Re: [pcplantdb] server-client split,
John Schinnerer, 06/16/2005
-
Re: [pcplantdb] server-client split,
Chad Knepp, 06/16/2005
-
Re: [pcplantdb] server-client split,
Richard Morris, 06/16/2005
-
[pcplantdb] server-client split,
Chad Knepp, 06/15/2005
-
Re: [pcplantdb] duck emergency,
Richard Morris, 06/10/2005
Archive powered by MHonArc 2.6.24.