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 <ken...@google.com> wrote: > 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 <alan.klig...@gmail.com> 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? > > > On Jan 7, 5:59 pm, Alan Kligman <alan.klig...@gmail.com> wrote: > > > 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_descriptor.output_type._concrete_class, callback=lambda > > > x:None) > > > in python/google/protobuf/service_reflection.py? > > > > If, for example, I'm running in a single thread and my underlying > > > channel is blocking, it's strange to pass a callback in when control > > > would normally return to the calling method after CallMethod has > > > completed synchronously. > > > > Thoughts? > > > > a --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
