Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] server-client split

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: john@eco-living.net, pcplantdb <pcplantdb@lists.ibiblio.org>
  • Cc:
  • Subject: Re: [pcplantdb] server-client split
  • Date: Thu, 16 Jun 2005 19:02:43 -0500

John Schinnerer writes:
> Aloha,
>
> With your clarifications below...
>
> > 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.
>
> > 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 think I grok what you're doing well enough to say it sounds good
> and modular and go for it.
>
> > 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!
>
> Yeah, pretty nifty. Any 'gotchas' that you're aware of?

Well the only gotcha is that it probably won't work on ibiblio without
some help from the admin either by upgrading python so we have
CGIXMLRPCRequestHandler (python 2.3 or later) which can use an
existing http server to do xml-rpc via cgi (very clever I think) or
run a custom xml-rpc on some server that is externally accessible.
I'm not sure this would work on login/tribal by default although I
haven't tried. Anyway, this isn't a pressing issue until Richard or I
start writing custom clients to import other datasets... which is what
I see one of the big uses/benefits of going this route. I think the
default client for the majority will forever be the web/html one.

> For example, when you say "importing a package over http" I assume you
> don't mean actually transferring the package modules (the files)...right?

Not at all, functionally it feels that way, but the reality is that
it's translated to xml and then translated back to data in your
client. I've already written one small program with it (status) and
I've been very impressed. Too me it feels a little like a python
import statement but with an url in it.

> cheers,
> John S.
>

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




Archive powered by MHonArc 2.6.24.

Top of Page