Remote Objects via CGI?

[kpd]

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?

[Fredrik Lundh]

Re: Remote Objects via CGI?

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>

[Diez B. Roggisch]

Re: Remote Objects via CGI?

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

[kpd]

Re: Remote Objects via CGI?

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.

[Fredrik Lundh]

Re: Remote Objects via CGI?

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>

[kpd]

Re: Remote Objects via CGI?

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 SimpleXMLRPCSer ver import CGIXMLRPCReques tHandler
def test( theList ):
return len(theList)

server = CGIXMLRPCReques tHandler()
server.register _function(test)
server.handle_r equest()

../test.py:
from xmlrpclib import ServerProxy, Error
server = ServerProxy("ht tp://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 CGIHTTPRequestH andler
serv = HTTPServer(("", 8080), CGIHTTPRequestH andler)
serv.serve_fore ver()


The code comes from a the python docs and an old list message at

http://mail.python.org/pipermail/tutor/2001-January/003142.html