xmlrpclib and generators
ken at seehart.com
Wed Jun 10 20:09:46 EDT 2009
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
>> 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
> Have you looked at Pyro?
Not yet. Looking at it now. Thanks, it looks like Pyro may be very
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list