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: Fri, 17 Jun 2005 10:24:23 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page