Re: Return value from CallMethod, default callback

2009-01-08 Thread Alan Kligman
That's right. This will only work in code that runs synchronously. If your program is written to be asynchronous then you will need to pass a callback, so you wouldn't use this at all. That's why I brought this up in the first place. If the channel can tell, based on the callback it receives, whe

Re: Return value from CallMethod, default callback

2009-01-08 Thread Pavel Shramov
On Thu, Jan 08, 2009 at 10:00:35AM -0800, Alan Kligman wrote: > That's one way to do it. You can do one better( without threading, > that is ) like this, though: It's not better but 'looks more simple'. From threading only Condition is used which is very cheap compared to network interaction. Your

Re: Return value from CallMethod, default callback

2009-01-08 Thread Alan Kligman
That's one way to do it. You can do one better( without threading, that is ) like this, though: def call( method, request ): class callbackClass( object ): def __init__( self ): self.response = None def __call__( self, response ): self.response = respon

Re: Return value from CallMethod, default callback

2009-01-08 Thread Petar Petrov
On Wed, Jan 7, 2009 at 7:07 PM, Kenton Varda wrote: > Sounds fine to me, but it's up to Petar (cc'd). > There's a pending CL. I think it will be submitted in the internal repository in a day. Should be available in SVN soon. > > On Wed, Jan 7, 2009 at 7:04 PM, Alan Kligman wrote: > >> >> Ya, t

Re: Return value from CallMethod, default callback

2009-01-07 Thread Pavel Shramov
On Wed, Jan 07, 2009 at 06:23:31PM -0800, Alan Kligman wrote: > > I poked around a bit and the code above isn't correct (for a couple of > reasons). But the question remains: should stubs be generated that > return the response down the callstack instead of passing it through a > callback function

Re: Return value from CallMethod, default callback

2009-01-07 Thread Kenton Varda
Sounds fine to me, but it's up to Petar (cc'd). On Wed, Jan 7, 2009 at 7:04 PM, Alan Kligman wrote: > > Ya, that's exactly what I'm experimenting with now and precisely what > I'm looking for. Would be perfect if the callback had a default value > of None too. > > a > > On Jan 7, 10:02 pm, Kento

Re: Return value from CallMethod, default callback

2009-01-07 Thread Alan Kligman
Ya, that's exactly what I'm experimenting with now and precisely what I'm looking for. Would be perfect if the callback had a default value of None too. a On Jan 7, 10:02 pm, Kenton Varda wrote: > I believe there was a proposal internally that if the caller passes None for > the callback, the R

Re: Return value from CallMethod, default callback

2009-01-07 Thread Kenton Varda
I believe there was a proposal internally that if the caller passes None for the callback, the RPC implementation should block until completion and then return the result. Does that seem like what you want? On Wed, Jan 7, 2009 at 6:23 PM, Alan Kligman wrote: > > I poked around a bit and the cod

Re: Return value from CallMethod, default callback

2009-01-07 Thread Alan Kligman
I poked around a bit and the code above isn't correct (for a couple of reasons). But the question remains: should stubs be generated that return the response down the callstack instead of passing it through a callback function? On Jan 7, 5:59 pm, Alan Kligman wrote: > Does it make sense to chang

Return value from CallMethod, default callback

2009-01-07 Thread Alan Kligman
Does it make sense to change stub.rpc_channel.CallMethod( method_descriptor, rpc_controller, request, method_descriptor.output_type._concrete_class, callback) to return stub.rpc_channel.CallMethod( method_descriptor, rpc_controller, request, method_descri