pcplantdb

[Chad Knepp <pyg@galatea.org>]

John Schinnerer writes:
 > Aloha,
 > 
 > > ...  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)
 > 
 > I thought we were going to define an XML DTD for data returned by the 
 > server, as an open standard for all clients to work with.

Sure that really hasn't changed, but I'm not feeling the need to do it
soon.  See below.

 > What will the server be returning, then?
 > 
 > >... 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.
 > 
 > Remind me what kfml is again...and why is data in the database being 
 > marked up with it?

Kung Fooey Markup Language, the internal xml of the database.  It
currently consists of only one tag <link/> which are internal
references.

 > In short, what happened to all our conversations about XML as our 
 > universal data transport markup to and from the DB/server 'engine'?

1. We only have one client and that client doesn't really require an
   xml transport layer.

2. We are kind of in a hurry and no other clients are slated for
   development within the current funding iteration.  Why exert the
   effort to add a feature that won't be used.

3. I have also proposed that the client server transport mechanism be
   implemented with xml-rpc/soap which goes one step further and
   translates the xml back to data in the client.  The only limitation
   is clients would need to be written in languages that have xml-rpc
   bindings.  

4. We can always add the necessary hooks into the server for client
   services as needs and funding mandate.

 > > 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.
 > 
 > Sounds good, aside from me still wondering what it's going to return.
 > 
 > > 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.
 > 
 > Can you explain what you mean by "client" in all the above?  I think I 
 > am visualizing something different than you.
 > 
 > Can you also please create some kind of diagram of your proposed 
 > software architecture?  That may clear up a lot of wordy questions and 
 > answers, from me anyhow.

I'm not really good with diagrams... although maybe I can describe it
well enough.  I think the server should provide the following
services:

1. Authentication.  The server should not need to trust the client at
   any point.  Clients that fail to provide appropriate authentication
   will be refused.

2. Database connectivity.  The server will be responsible for all
   interactions with the database (necessary for 1) and will implement
   the following API (roughly):

   A. Search methods (various)

   B. Retrieving (unformated) data such as plant reports,
      comment/topic threads/content, images, relationship webs, etc.

   C. Adding/editing data (if authenticated) such as in B

The client would be responsible for formating the output, getting
input from the user, and translating the user input into something
understandable to the server API.  Although the client sounds simple
it's at least two thirds of the work.

 > It's 9:06 PM in Hawai'i - do you know where your ducklings are?  :-)

Well, I know one is in the belly of a snapping turtle, that will soon
be in my belly.  Does that mean that my duckling will be in my belly?


John Schinnerer writes:
 > Aloha,
 > 
 > OK, here's an example of where I'm not following what you're up to.
 > 
 > >  > > 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.
 > 
 > So who/what is returning specific html markup like this?
 > Not the server, I assume/hope...?

Absolutely not.  

 > So where will this be coming from, and how will it end up being 
 > 'wrapped' this way?  That is, how does whatever is receiving it and 
 > wrapping it know what to wrap and how.
 > And what is going to be using these 'wrapped' result data?
 > 
 > And how will whatever piece is doing the wrapping know a set of results 
 > from a result in that set from a family/species designation from a 
 > text/description designation and so on?

I'm currently headed toward handing dictionaries (structures in
xml-rpc) to the client (results("family") = "gjiews", results("genus")
= "asdfdsf" , results("text") = "This plant is random and unreal..."),
which is much nicer than handing a raw table row to the client.  It
also allows for [some] changes in the database schema without breaking
the client.  The client is completely responsible for the markup.

 > I thought this was going to be passed back and forth using XML markup 
 > that we create to suit our descriptive needs and purposes - see the 
 > sample (Rich, I assume you did that?) in the wiki spec pages.

It still is.  The beauty of xml-rpc is that the process of marking it
up in the server and then the process of translating it back to data
in the client is transparent... in other words I'm kind of dropping
the xml think because we don't need to do it!
<ttp://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html> has
some good examples of xml-rpc in five different languages.

 > How many of the regretted implementation choices that will be re-chosen 
 > RSN could have been made better in the first place if we actually worked 
 > out in-depth schema issues, a reasonably detailed and thorough 
 > functional spec, software architecture diagrams, etc.?

I don't think this will be our problem but I tend to not worry about
things like that.  Besides rewriting something is way easier the
second time.

 > John S.
 > 
 > -- 
 > 
 > John Schinnerer - MA, Whole Systems Design
 > ------------------------------------------
 > - Eco-Living -
 > Whole Systems Design Services
 > People - Place - Learning - Integration
 > john@eco-living.net
 > http://eco-living.net
 > _______________________________________________
 > pcplantdb mailing list
 > pcplantdb@lists.ibiblio.org
 > http://lists.ibiblio.org/mailman/listinfo/pcplantdb

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