[Pipet Devel] http protocol

[Brad Chapman]

Gary wrote:
> I'm not an http expert either; I merely proposed it because it is the
> default communication protocol for XML transfer, and web-browsers use
> it.  When we get XML compliant web browsers, then we can connect
> browsers to a loci engine.  The crappy part about this is that, in 
order
> to manipulate the DOM, we're stuck with java/javascript.  I dont 
know of
> any other way to do client-side processing through a browser, if 
there
> is I would love to hear about it.  Honestly, the whole web-interface
> idea may be too much for us right now, although I know Dr. Lapointe 
is
> interested, as is my roommate (who would like to participate in this
> aspect of Loci's interface).  

Good timing, since I'm just programming/thinking on this right this 
second!

    Right now I'm starting to implement and work through the 
microscope server example that I mentioned in my e-mail earlier today. 
This server does a lot of what Jeff mentioned he wanted, including 
allowing multiple connections to a single server. The connections 
are established through sockets (socket programming = scary!) and the 
server handles processing requests, authorizing users, and 
returning information. It works with a web interface by creating a 
simple http server that spits out a basic page and a jar file with the 
client.
    So, anyways, looking at this and looking at basic info on http led 
me to have the following thoughts:

1. I don't think http as a communication protocol will give us a 
multi-client/one server setup like we would like without a huge pain. 
>From looking at things, http seems set up for a simple request and 
response dialog, and I'm not positive how to manipulate it to do what 
we want without having a huge middleware server with a lot of "web 
interface" specific code.

2. How about if instead of relying on the middleware server to spit 
out XML that will eventually be good enough to travel directly into a 
browser (whenever browsers become sufficiently XML aware enough), we 
require the web front to process the XML that the middle returns, and 
then serve up web pages based on this? From what little I know about 
Zope, it seems like it would be ideally suited to this task since I 
think it's meant for publishing "dynamic" web pages like we would need 
for Loci. This way, the developer of the front end could choose use a 
"real" http server (instead of us having to program an http server) 
and could also use other web server tools like MySQL or whatever. This 
seems like it would free up the people interested in developing the 
web interface to be a lot more creative in generating the user 
interface and also to use more standard web tools that we actually 
have now.

3. If the above two points make sense, then we now have a little 
more flexibility for communication methods between front ends and the 
middle. In this case, I would like to propose using corba (instead of 
the sockets used in the microscope server example that I'm looking at) 
to communicate between the front and the middle. This will give us a 
lot of freedom for creating a nice interface and will allow front ends 
to be built in any language. Initially, we could have corba servers 
publish there IORs somewhere on the bioinformatics.org server, and 
then as we got more users, have a dedicated loci program that 
manages/distributes these IORs.
    I also think corba might be a little kinder to us then 
sockets/http in terms of a learning curve.

    Again, I think that once we have corba working, the middle could 
be extended later to use other protocols (once xml and browsers start 
to get along better). But this would give us a way to create the web 
interface with tools we have now.
    Does this sound like a plan? What do the web interface people 
think of this type of arrangement? Does it make sense? (I'm not much 
o' a web programmer myself). If you think it might be worth a try, I 
can whip up an idl interface to start with and we can go from there...

Brad