[Pipet Devel] http protocol

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> 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.

What makes it an 'http' server is simply that fact that the formatting, etc.
adheres to the http 4.0 protocol.  Otherwise, it's just communication through a
socket.  For Loci, we can throw most of the http stuff away.

I know Gary was pushing to get this dialog to happen over http so that the
middle and fronts can be in 2 different places.  We can make something using
Internet sockets, but I think going through a big ol' natsy Web server like
apache is 90% overkill.  AND it does not give us a number of the things we
need, including multicasting and persistence.

I think our first priority is to get the dialog running locally.  Next we can
look at getting 2 middles to talk to each other over the Internet.  And last,
we can look at getting the fronts and the middle talking over the net.  I'm not
saying to not do it.  We just need to take it one step at a time.

> 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.

Again, http is overkill.  We need an LTP: Locus Transfer Protocol.

> 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),

As I wrote in my last message, I think the XML needs to be processed by the
Loci front and not by the Web browser.

> we require the web front to process the XML that the middle returns, and
> then serve up web pages based on this?

Zactly.

> 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. 

It may work, but are we going to make THAT monster a requirement?

Perhaps a little php will do the trick.

> 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.

Boy, corba has to sneak in somewhere ;-)

Are you proposing to run a 'streaming dialog' through corba?  I didn't think it
was used for such a thing.

>     I also think corba might be a little kinder to us then
> sockets/http in terms of a learning curve.

As David mentioned, sockets are pretty straight forward.  I think corba is an
order of magnitude more complex.

>     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.

Please, please, don't let http and the Web paradigm dictate how Loci will work,
Brad.

Loci can use corba and http, having the appropriate extensions for them.  But
we have to keep Loci as a protocol-agnostic broker for communications.

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+