«

Three are lots of good looking remote-object implementations for Python
such as Pyro, Rpyc, and PyInvoke. All of these require a deamon
running to serve the remote objects.

Has anyone seen a method of doing this using CGI or FastCGI instead of
a deamon? I'm not worried about performance for this application, but
I do have constraints on long-running processes.

I do want to stay away from XmlRpc if possible.

Do you have any suggestions?

kpd wrote:

> Has anyone seen a method of doing this using CGI or FastCGI instead of
> a deamon? I'm not worried about performance for this application, but
> I do have constraints on long-running processes.
>
> I do want to stay away from XmlRpc if possible.

because?

</F>

kpd wrote:

> Three are lots of good looking remote-object implementations for Python
> such as Pyro, Rpyc, and PyInvoke. All of these require a deamon
> running to serve the remote objects.
>
> Has anyone seen a method of doing this using CGI or FastCGI instead of
> a deamon? I'm not worried about performance for this application, but
> I do have constraints on long-running processes.

This is pretty much a contradiction to what pyro (the others I don't know,
but I bet they are similar) does: serve requests from in-memory living
stateful objects.

CGI on the other hand will spawn a new process for each request, discarding
quite a few aspects. You'd have to re-instantiate the serving objects for
each request, if you want to keep the statefulness, you have to persist
state between requests and ensure there is some session state communicated.

All in all, it can't be done so easily as by only adapting an existing
RPC-solution, but you rather should roll out your own. Or stick with what
is available, like XMLRPC

Diez

I did not have much hope, but thought there might be something. I was
thinking of going this route to get a very quick solution to a python
fat-client adding to or retrieving objects from a community repository
over http.

XMLRpc could work if there is a CGI solution, although the data sets do
not lend themselves to XML. They are tuples of 6 floats about 2000 to
a data set.

I did just find out today that CherryPy can support different apps in
'branches' so that may be the right way to go.

Might just have to do it the right way with a real CGI app.

kpd wrote:

> I did not have much hope, but thought there might be something. I was
> thinking of going this route to get a very quick solution to a python
> fat-client adding to or retrieving objects from a community repository
> over http.
>
> XMLRpc could work if there is a CGI solution, although the data sets do
> not lend themselves to XML. They are tuples of 6 floats about 2000 to
> a data set.

sounds like native HTTP plus mime/multipart messages is all you need.
just POST or GET to a CGI script, and use the email module to create and
pull apart the messages.

</F>

Thanks Fredrik. I gave XmlRpc a shot as you implied earlier.

It works like a charm. This is how I tested quickly locally without a
large web-server installed:

1. Run cgiserver.py - this takes the place of the normal web server.
2. Then run test.py to make a local xmlrpc call.


../cgi-bin/xmlrpcserver.py:
from SimpleXMLRPCServer import CGIXMLRPCRequestHandler
def test( theList ):
return len(theList)

server = CGIXMLRPCRequestHandler()
server.register_function(test)
server.handle_request()

../test.py:
from xmlrpclib import ServerProxy, Error
server = ServerProxy("http://localhost:8080/cgi-bin/xmlrpcserver.py")
theList = [ 1.1, 2.2, 3.3, 4.4 ]
print server.test( theList )

../cgiserver.py:
from BaseHTTPServer import HTTPServer
from CGIHTTPServer import CGIHTTPRequestHandler
serv = HTTPServer(("", 8080), CGIHTTPRequestHandler)
serv.serve_forever()


The code comes from a the python docs and an old list message at
http://mail.python.org/pipermail/tut...ry/003142.html