pcplantdb

[Richard Morris <webmaster@pfaf.org>]

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?


> 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>".
...

>  > 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']

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

Good stuff

        Rich