Hendrik van Rooyen wrote:
Ken Seehart wrote:
8< ------------ implementation --------------
The practical constraints of my specific application are:
1. The rpc server is a highly specialized slave system that does heavy duty
work.
2. The rpc client is itself a web server that dispatches work requests to the
rpc server(s) and displays the >current status of work done so far.
3. The generators will typically run for a long time (hours) and yield data
periodically (perhaps once a minute).
If this "yield" can be made to be, or if it is, supply side driven, instead of
yielding on demand like a
generator, then I would set up a simple TCP/IP peer to peer socket link and just
send the result
back when it is ready. If you have to "serve" more than one such link, it is a
simple matter
to keep a list of queues linking the different socket sets to the "generator",
and to iterate over
the list, putting a copy of the thing that was just produced into each queue.
Of course, the thing you want to pass back must be serializable.
It is supply side driven, and the content would be serializable. The
only reason I want something high
level like xmlrpc or Pyro instead of rolling my own stuff with TCP/IP is
that I want the client and server to be
easily customizable.
Have you looked at Pyro?
Not yet. Looking at it now. Thanks, it looks like Pyro may be very
relevant.
Ken
--
http://mail.python.org/mailman/listinfo/python-list
