[Pipet Devel] toolkit and data access/storage

[J.W. Bizzaro]

Justin Bradford wrote:
> I was under the impression that the CGI program would return an XML file
> which the client used for its display.

Well...actually the model is changing some now that Carlos will help with Paos
(see the messages we sent).  I'm using the term CGI-like, because at some
point, on the server side, the "query" or command will be passed from a Python
script (let's call it "Gatekeeper") to a stand-alone analysis algorithm (runs
from command line and returns XML).  The XML will then be returned to
Gatekeeper and sent back to the client.  This is a lot like a Web browser
(client) communicating with a CGI program (on a server).

> Using a browser connected directly
> to this would require additional information (javascript, style sheets,
> etc) for display, right? Or would the dhtml interface be conditional (only
> send it if it's not our special app client)?

Okay.  You're asking how will the XML accomidate the fact that the client can
be either a GUI loci or a Web browser?  Good question.  I want the XML to be
formatted to best accomidate the GUI loci (you know, the tools made with PyGTK
and all that).  The job of the person developing the Web/HTML interface
(Rahul) is to write a translator that will turn the XML into HTML + GIF.

> 
> Also, I think a typical, url-encoded CGI request syntax is poor for this
> system. There's no particular reason we couldn't feed the server program
> our own query syntax. I think using one of the proposed XML query
> languages would be more useful. I like AT&T's; it's a mix of XML and
> semi-structured query language (halfway between SQL and OQL).
> It lets you specify the format of the XML returned.
> This could be tied to a database or analysis program, or a mixture of
> both. A client can take whatever pieces of information from any source it
> likes and combine them for it's display.

Again, we are going with distributed Python objects via Paos.  But the "query"
or command language used is something I haven't thought much about.  We do
want the XML that is returned to be something the client can handle.  For
example, the client asks (queries) the Gatekeeper for a Chao-Fasman prediction
of protein secondary structure.  It should get something back that can be
displayed by that client, or the client may have to pass the info along to
another client.  In any case, the data has to be of the type that has a client
in existence for it.

Maybe the client doesn't need to say what it is expecting.  Maybe we just need
a filter for things not expected.  If we do get something unexpected, it may
be the fault of analysis algorithm author who tried to implement something not
supported.  (BTW, we do need a specification and a template system for
converting analysis loci output into XML that the clients can handle--falls
between the Gatekeeper and the analysis loci).

> The basic idea is like the Casbah project, just not so complicated, and no
> Java. I'm working on the basic idea for a database/application
> infrastructure for education related ideas.
> 
> XML-QL (AT&T's proposal):
> http://www.w3.org/TR/NOTE-xml-ql/
> 
> XQL (Microsoft's proposal):
> http://www.w3.org/TandS/QL/QL98/pp/xql.html

I would like you to consider what query language we need, that would best suit
XML transfer.  But since this is a GNU-only project, we can't go with a
proprietary language. ***Besides, those are more complex because they need to
be general purpose.  Can you invent something along those lines that is small
and special purpose for Loci?

> 
> I'm not quite sure how the interface layer between the query parsing and
> database retrieval and/or application will work yet. Ideas are welcome.

You mean the program that takes the query, converts the query to a
command-line, issues the command to the analysis loci, accepts the ASCI text,
converts it to XML, and sends it back to the client?  Once again, the
Gatekeeper!  That's a BIG component to Loci that needs to be set up before
most anything else will work.  Of course it will be in Python and be closely
connected to Paos.  Who wants that project???  It is actually a part of
defining a query langauge and the protocol for handling XML.  Do you want to
take a shot, Justin?  The other XML projects are (1) converting standard docs
like PDB and GENBANK to XML, and (2) parsing XML to display images within the
client loci.

> 
> Also, do we want a listserv? If so, I can have something set up here.

Heh.  I know it's getting too much for me to handle.  Can you set something up
until I get some servers going at UMass Lowell for this project?  Thanks!  The
list of people that got this message (including you and me) is the whole
mailing list.  BTW, Jay Painter is off the list...he's working too hard on
getting GNOME ready for RedHat 6.0.



Jeff
-- 
J.W. Bizzaro                  Phone: 617-552-3905
Boston College                mailto:bizzaro at bc.edu
Department of Chemistry       http://www.uml.edu/Dept/Chem/Bizzaro/
--