yep, sounds good Eric. Yeah, if an interceptor needs complex processing, might as well implement ClientInterceptor and use any of existing supporting entities like ForwardingClientCall, SimpleForwardingClientCallListener etc.
On Mon, Jul 20, 2020 at 12:39 PM Eric Anderson <[email protected]> wrote: > On Mon, Jul 20, 2020 at 8:54 AM Sivabalan <[email protected]> wrote: > >> On Mon, Jul 20, 2020 at 11:02 AM Eric Anderson <[email protected]> wrote: >> >>> This mainly supports "observing" client interceptors, that don't need to >>> make any changes to the RPC other than Metadata. That helps many, but lots >>> of interceptors need more power than this. It's still fine to have a >>> simpler version in certain scenarios. >>> >> thanks. Can. you throw some light on what more power you are >> insinuating. >> > > You can have interceptors that implement retries by calling Channel next > multiple times. You can have caching interceptors that respond without > using Channel next by calling the Listener directly. You can have > validating interceptors and fault injection interceptors that fail calls. > You can have interceptors that copy data from the request into Metadata so > that it can be used for load balancing. You can have interceptors that look > up custom proto options from the MethodDescriptor to configure themselves. > You can have interceptors change the deadline if it is too large or missing. > > If it *just* had Metadata, especially request metadata, then its limits >>> would be more obvious. But users frequently ask how they fail a call, and >>> you can't fail a call with this type of API. I'm not sure users would >>> realize the API has that limitation. But with some documentation maybe that >>> could be addressed. >>> >> - Yeah, I haven't thought much about failing/cancelling a request >> from an interceptor. Will see if how I can abstract that out as well. >> > > I wouldn't suggest trying to support "all the cases." The current > interceptors are complex to allow "all the cases." Current interceptors see > *everything* between the application and gRPC, so they can do *whatever > they want.* I think the most gains would be gotten by limiting the > functionality available, thus simplifying things when the use-case is > supported. So you target common use cases and try to simplify those. > -- Regards, -Sivabalan -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CABeKz3%3DfYsrT484sUR4bn1OmXMQvTMRzn2WFPwXtYA-akyu%2B3g%40mail.gmail.com.
