[Pipet Devel] http protocol

[Brad Chapman]

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

Okay, this makes sense. Sorry I'm a little confused about the ol' http 
stuff. You'll have to keep in mind that 6 months ago I didn't know 
the difference between a web browser and a web server :-O
 
> 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.

    My idea was that the web front would take care of all of the 
serving for web pages, and the middle would only supply this Loci 
Transfer Protocol (ie. XML back and forth). I figure that whoever does 
the web front can use whatever server/helper programs that they need, 
and I was just throwing Apache/Zope out there as ideas, since Gary 
expressed some concern about the feasibility of things. I think 
getting a loci front going in a web browser will take a lot of 
creativity, so any tools that can help shouldn't be a problem!
    Besides, if you get to require "monster" Gnome and Gtk for the 
front end you are designing, I think anyone working on the web front 
end could also require Zope/Apache :) 
    But, as I said, I don't know anything about web design, so 
whatever people want to use is fine with me!

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

Right, baby steps all of the way. I just uploaded my first baby step 
with sockets to get the front and middle talking on a single machine. 
I wrote a barely functional middle "socket" server based heavily on 
the design of the microscope server, and then redirected the 
connection stuff so it goes through the socket. So now we actually 
have clean language independent separation between one small part of 
the front and middle (yay!). 
    Okay, right now I have the middle socket server and the main Loci 
program start up via two different scripts (to make it easier for me 
to test things) so to start Loci now you need to first run:

./startMiddle.py &

and then:

./loci &

If you try and start up loci without the middle running you'll get a 
socket error.
    So it looks like we'll start doing things with sockets and see 
where it goes....

> Boy, corba has to sneak in somewhere ;-)

But of course!

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

Sure, I think it could. You can run multithreaded servers, and _I 
think_ it supports callback functions.
 
>>     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.

    I think that initially sockets are simpler, but I think things 
might get more difficult as we want to do more complicated things. 
This is where I think corba might be more suitable. 
    But you are right, maybe we should start with sockets and then see 
if problems/limitations develop. Then maybe I'll be able to make a 
better case for
corba...

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

This makes sense, but I only want to have to support one communication 
protocol from the front to the middle for now. Otherwise stuff will 
get waaay too complicated for my brain to handle.

Brad