yes, backward compatibility is definitely another issue we should think about.
-Ian. On Mon, Mar 4, 2019 at 12:18 PM yuhang xiu <[email protected]> wrote: > Hi, > > About compatibility issues. > > The current version will enter onResponse due to all requests (correct or > incorrect). If we modify the code, the correct response enters onResponse, > the error response enters onError, and onResponse will only process the > correct request if the user does not modify the Filter code. > > Is this a problem that we should consider? > > Ian Luo <[email protected]> 于2019年3月3日周日 下午10:49写道： > > > Jun, > > > > In your new proposed interface, how could we construct a filter chain? > Say, > > how could filter-a process further a value processed by filter-b? > > > > Thanks, > > -Ian. > > > > > > On Fri, Mar 1, 2019 at 5:44 PM jun liu <[email protected]> wrote: > > > > > Hi, > > > > > > I am thinking of the possibility of changing the current Filter > > definition > > > model to make it totally asynchronous and event-driven. Here’s the > > detailed > > > proposal[1]. It’s only a immature idea at present so I am not sure fi > > it’s > > > good to have this change yet, especially from the user’s side. > > > > > > In short, the new Filter would look like: > > > > > > public interface Filter { > > > void onSend(Invocation invocation) { > > > // before invoke, throw exception to terminate > > > } > > > > > > void onResponse(Result result, Invoker<?> invoker, Invocation > > > invocation) { > > > // biz return successfully > > > } > > > > > > void onError(Throwable e) throws RpcException{ > > > // biz throw exception > > > } > > > } > > > > > > 1. https://github.com/apache/incubator-dubbo/issues/3585 > > > > > > Jun > > > > > > > > >
