xmlrpclib and generators

[Ken Seehart]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090610/d36b30c8/attachment-0001.html>