Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] server-client split

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: pcplantdb <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] server-client split
  • Date: Thu, 16 Jun 2005 09:28:01 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page