For legacy filter implementations with all logic inside “invoke()”,
compatibility would be a problem. I am not thinking of it yet.
Jun
> On Mar 4, 2019, at 6:49 PM, Ian Luo wrote:
>
> Jun,
>
> The method signature is totally different. Are you indicating a default
> bridge method to address t
Jun,
The method signature is totally different. Are you indicating a default
bridge method to address this particular concern?
Thanks,
-Ian.
On Mon, Mar 4, 2019 at 4:44 PM jun liu wrote:
> > If we modify the code, the correct response enters onResponse,
> > the error response enters onError,
> 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.
For legacy filters only implement onResponse, I think we can solve this by
redirecting onError
> In your new proposed interface, how could we construct a filter chain?
I don't think we still need a nested Filter chain as before, the new Filter can
simply work as follow:
Iterate(filters) {
filter.onSend();
}
Result result = invoker.invoke();
result.whenComplete((value, t) {
Iterate
yes, backward compatibility is definitely another issue we should think
about.
-Ian.
On Mon, Mar 4, 2019 at 12:18 PM yuhang xiu wrote:
> Hi,
>
> About compatibility issues.
>
> The current version will enter onResponse due to all requests (correct or
> incorrect). If we modify the code, the cor
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
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 wrote:
> Hi,
>
> I am thinking of the possibility of changing the current Filter definition
>
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.
I
