[Tutor] Starting a browser instance and passing a parameter to it.

[Don Taylor]

Eric Brunson wrote:
> Don Taylor wrote:
>> Eric Brunson wrote:
>>
>>   
>>> Definitely,  or even just CGIHTTPServer.
>>>
>>>     
>> No, I don't think so.  I am not a RESTafarian.  :-)
>>   
> 
> Forgive my inexperience with the SimpleXMLRPCServer, but I didn't think 
> it provided state any more than any other connection oriented server?  
> Am I wrong about that?
> 

Eric:

I am sorry about being flippant in my earlier reply to you - I am not 
really that religious about this stuff.  I am just interested in using 
xml-rpc or json-rpc as a way to glue a browser UI onto a stand-alone 
Python application.

As I understand it, a web-server like Apache is a connection-oriented 
server and so is a stand-alone XML-RPC server.  Both open a port and 
listen for, and respond to, requests on that port until they are 
terminated.

A CGI server application behind Apache, however, is effectively a 
connectionless server.  It accepts one request at a time from any 
client, processes that request, and sends a response to the requester.

A server application embedded within an XML-RPC server (as a set of 
function or method calls) is still connection-oriented.  There is only 
one process running.

If you create a stand-alone SimpleXMLRPCServer (that is not behind a 
web-server, but having its own socket service) then you can write 
service routines that work almost as if those routines were part of the 
client's process.  If the service routine saves something, opens a file 
or whatever, then the next time the client calls that server the state 
is still there.  You could write service routines to open a file, write 
to it and close it.  If you called these routines in order from the 
client then they would do just what you expected.  (This is assuming the 
server only has one client - which is what I am doing).  The server runs 
as a long-running process - it runs until it is terminated.

If you contrast that with a CGI web server application then the server 
application is short-lived - it exists only for the duration of a single 
transaction with its client. Because it can have no memory of what 
happened on previous instantiations it must somehow pass state back at 
the end of a transaction so that the web client can re-send it to the 
server the next time that the client wants some work done.  Cookies and 
url rewriting are a couple of techniques for passing state back and 
forth between client and server.

All of the above is a gross simplification, is probably bs and I am sure 
is stuff that you know better than I do.

Don.