pcplantdb

[Richard Morris <webmaster@pfaf.org>]

Chad Knepp wrote:
> 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.
I guess this will be a case for some things in issue tracker.

> 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 think there is an XML query type language. Might be worth 
investigating. I'd had good experience of passing XML as requests to 
servers.

>  > > 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!

This is all sounding good. I think we should update the spec pages
with this. Might get onto it today if thats OK.

Rich