On 11/30/2011 04:10 PM, Sergey Beryozkin wrote:
> On 30/11/11 13:12, Bill Burke wrote:
>>
>>
>> On 11/29/11 11:58 AM, Sergey Beryozkin wrote:
>>> Next the only other case I can see us needing to address in the future
>>> versions of the spec is support for the suspended invocations.
>>> I'd do
>>>
>>
>> I don't see why you'd need support for suspended invocations within the
>> filter api. Especially when you have suspend methods within
>> ExecutionContext.
>>
> That is my concern too, a filter updates or blocks the request and keeping the filter spec as simple as possible is a
> way to go IMHO as opposed to designing the filter api around something that will allow the filters assume the role of
> endpoints doing the actual job...And even if filters will do be able to do then it would need to be managed internally,
> possibly with the help of FilterContext
Non-blocking filters are one example. If the data are not fully available, the filter releases the thread and waits for
more data to come. Once the data are available, filter chain i resumed.
But suspend is not the only extension. There may be other potential use cases, which we may not see yet. We are only
starting with filters right now.
Marek
>
> Cheers, Sergey
>
>> Bill
>>
>