[Pipet Devel] toolkit and data access/storage

[Justin Bradford]

On Thu, 21 Jan 1999, J.W. Bizzaro wrote:
> 
> Yes, that is exactly what the Web interface is targeting :-)  But can we put
> all of the bells and whistles in the Web interface that we have available with
> GTK?  There is just no way right now.  As I said in my last e-mail to Carlos,
> we want Loci to be as dynamic as Word and Excel.  If Microsoft can't put those
> in a Web browser, I certainly doubt we could put Loci.  The Web interface will
> simply have to work with the limitations imposed on that type of interface.
> 

A Windows port using gtk should not be a significant problem. A
cross-compile with cygnus' tools and Win gdk, should be all that's
necessary. Theoretically Mac OS X should be even less work (once someone
ports gdk).
I agree, though, that for development purposes, it's best not to even
worry about it. Linux is where we'll find the most contributors in the
early phase of development.

> Yes it would be a client in the way it would substitute for all (nearly) of
> the client side loci.  But it would act as a Web server (really, work with a
> Web server) that can be tapped into by anyone using a Web browser.  Where
> should it go?  I think we may just need one at the main Loci URL (which
> doesn't exist yet).  Why do you think it should be portable?  It can be, but I
> don't think it has to be, as long as one Web server can handle the requests.

I was under the impression that the CGI program would return an XML file
which the client used for its display. 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)?

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.

And for now, it could still be implemented over a typical HTTP
connection, via an intermediate "dispatch" agent.

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

Supposedly, there was a conference on query languages a while back, but I
haven't seen any working drafts on w3 yet. It's hard to tell which becomes
the recommendation (probably a mixture of the two).

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.


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

Justin Bradford
justin at ukans.edu