I strongly concur with Eric. As we also discussed offline, I am against the per-channel wait_for_ready value for two primary reasons:
1. we should be conservative when adding APIs, as we can easily add but cannot remove APIs. If this turns out to be a massive user concern, we can resolve it later. 2. additional complexity of defining the semantics when per call and per channel values are present (or absent), which ties closely to Eric’s concern of non-obviousness of behavior. On Wed, Oct 17, 2018 at 6:00 PM 'Lidi Zheng' via grpc.io < [email protected]> wrote: > Got it, thanks. > Do you know why Python version doesn't have the a subset config class? > Should this feature be implemented in that way? > It seems that will be inconsistent with previous `timeout` variable. > > On Wed, Oct 17, 2018 at 5:53 PM Eric Anderson <[email protected]> wrote: > >> On Wed, Oct 17, 2018 at 5:49 PM Lidi Zheng <[email protected]> wrote: >> >>> Both designs are valid for me, it can be convenient when users want an >>> easy way to adopt this logic to all of their RPC calls. Especially for >>> users who doesn't implement fallback logic for RPC calls. >>> >> >> It's dangerous because users "pay" for the complexity even if they don't >> use the feature. Because now they (as us when we help them debug) have to >> determine what the setting is. >> >> It has the potential to replace the existing `grpc.channel_ready_future` >>> function. >>> >> >> Definitely. +1. But that is true in either case I think. >> >> >>> And it can make the logic of Python API more similar to `client_context` >>> in C++ or `CallOptions` in Java and Golang. >>> >> >> Except in C++ and Java those settings *don't* apply to the entire >> Channel. They may apply to a subset of calls, but the user has good control >> over what. >> >> >>> >>> On Wed, Oct 17, 2018 at 5:20 PM Eric Anderson <[email protected]> wrote: >>> >>>> On Wed, Oct 17, 2018 at 4:52 PM lidiz via grpc.io < >>>> [email protected]> wrote: >>>> >>>>> * (Suggesting) Add an optional `wait_for_ready` variable to `Channel` >>>>> class initialization method. Default `None`, accept `bool`. >>>>> >>>>> >>>> Please don't. wait_for_ready changes the semantics of the call enough >>>> that you don't ever want to wonder what the current value is. You need the >>>> wait_for_ready configuration *very* close to the code doing the RPC. >>>> >>> -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/CAMC1%3Djezna9YkAmRuiJQNL5WbDjmxSTA7aOz756y7R-1DQa%2B6A%40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CAMC1%3Djezna9YkAmRuiJQNL5WbDjmxSTA7aOz756y7R-1DQa%2B6A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CABdARdBMAhqKoQP8_cFW0%3D4WP3K6M_a-hRkxRv58KMciTby79g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
