On 01/12/11 14:57, Marek Potociar wrote:
>
>
> 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.
It's a good idea to think about the future extensions and get prepared
for then as much as possible early, but IMHO this does not necessarily
have to 'spill' into the interfaces, return types that filter developers
will have to deal with during their regular filter development, as I
said in the initial response to your proposal,
FilterContext can serve as an extension base very well too
may be it should have a method such as
FilterContext.getContext(T class) right now and be done with it
ex,
filterContext.get(ExecutionContext.class).suspend
Will that work ?
Sergey
>
> Marek
>
>>
>> Cheers, Sergey
>>
>>> Bill
>>>
>>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com