pcplantdb

[Chad Knepp <pyg@galatea.org>]

Richard Morris writes:
 > Chad Knepp wrote:
 > > 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.
 > > 
 > Just tying to clarify things a bit more. And quite where xml-rpc fits in.
 > 
 > We need to specify what format the above methods produce.
 > 
 > Search:
 >      are these specified in some xml-rpc format? If not how                
 >           specified.
 >      What fields will be searchable?
 >      Free text only or can we specify a required range for heights?

The server should/will implement any kind of search that clients and
users feel they need.  This is definitely a server element because it
requires structural knowledge of the database.

There will be methods for free text as well as individual elements
such as height.  Perhaps in the future we can develop a free text
search grammar that allows uses a lot of control without having to use
long forms that list all the various elements.

 > > 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.
 > 
 >  From this I'm assuming that we have something like
 > 
 > result = Eden.Search('salix alba')
 > print "Botanical name " + result("genus") + result("species")
 > ...
 > 
 > or if we want an xml formatted output
 > 
 > result = Eden.Search('salix alba')
 > print "<BotanicalName><Genus>" + result("genus") +"</genus><species>" + 
 > result("species") +"</species></BotanicalName>".
 > ...

More or less exactly.  Markup/format is the clients job whether it's
html/xml/text or what have you.  It's possible to add an xml
middleware layer on top of the server to support clients that can't or
don't want to use xml-rpc.  Keeping it seperated from the server would
be my preference.

 > >  > 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.
 > > 
 > A python client example from above.
 > 
 >      import xmlrpclib
 > 
 >      # Create an object to represent our server.
 >      server_url = 'http://xmlrpc-c.sourceforge.net/api/sample.php';
 >      server = xmlrpclib.Server(server_url);
 > 
 >      # Call the server and get our result.
 >      result = server.sample.sumAndDifference(5, 3)
 >      print "Sum:", result['sum']
 >      print "Difference:", result['difference']

The way I think about it is that you are just importing a package over
http.  Crazy and cool.  Not only that but you can write the server in
one language and use the methods in any other language that supports
xml-rpc!

 > >  > 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.
 > 
 > Another question.
 > 
 > WHo's job is it to transfer a CGI GET or POST request (say those 
 > submitted by an html form) into a appropriate queries.

Client!!! Cookies as well.  Putting cookies into Eden is really what
started to mess things up and got me thinking it would be nice to make
a break.

 > Good stuff
 > 
 >      Rich

Ok, I gotta get back to it... hopefully have the client/server split
done today!

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