On Wed, Jan 7, 2009 at 7:07 PM, Kenton Varda <ken...@google.com> 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 <alan.klig...@gmail.com>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, 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to