Here another idea (not really sure it's a good one)

http://nopaste.info/0c43874851.html

It would be regrouping session created/open/close in one IoFilter
method, with a SessionEvent are a parameter.

I doesn't change much the inner logic, but perhaps it can make
impelemention of IoFilter less verbose.
WDYT ?
Julien

On Sat, Aug 20, 2011 at 8:49 AM, Julien Vermillard
<[email protected]> wrote:
> Hi,
> Because a filterchain can be shared across different sessions and
> threads, so you need to pass the local chain index because you can
> store it locally in the filter chain. Perhaps there is something
> smarter to do, because it's the dark point of this API.
>
> Julien
>
> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera <[email protected]> 
> wrote:
>> Why do we pass the current position?  We also seem to pass it twice in the 
>> method and the controller.
>>
>>
>> Regards,
>> Alan
>>
>> On Aug 19, 2011, at 1:10 PM, Julien Vermillard wrote:
>>
>>> Ok I committed the modification, for passing a chain controller to the
>>> filter for delegating the call to next filter.
>>>
>>> First I did it only for read & write chaining because the other events
>>> (created,open,closed,idle) are fine like they are. They don't need to
>>> block an event or send it multiple time to the following filter.
>>>
>>> Here the modified IoFilter, some controller interface are passed to
>>> read & write events :
>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/api/IoFilter.java
>>>
>>>
>>> Here sample implementation of LoggingFilter :
>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filter/logging/LoggingFilter.java
>>>
>>> Here the FilterChain implementation, still simple :
>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filterchain/DefaultIoFilterChain.java
>>>
>>> Now I need to figure how to remove the current position argument of
>>> the filter call.
>>>
>>> Julien
>>>
>>>
>>> On Fri, Aug 19, 2011 at 2:46 PM, Julien Vermillard
>>> <[email protected]> wrote:
>>>> I half implemented the controller idea, it's looking like working,
>>>> I'll finish that during the weekend or next week and commit it for
>>>> review.
>>>> Julien
>>>>
>>>> On Fri, Aug 19, 2011 at 2:39 PM, Steve Ulrich <[email protected]> 
>>>> wrote:
>>>>> Hi!
>>>>>
>>>>> Besides the points you mentioned, there are some other flaws:
>>>>> 1) How do you handle post-message-forwarding logic?
>>>>> 2) How do you handle filters that transparently push messages to the 
>>>>> underlying filters (e.g. keep alive)?
>>>>>
>>>>> So the filters should decide about what to do, the chain about the where.
>>>>>
>>>>> regards
>>>>>
>>>>> Steve
>>>>>
>>>>> There could be specific (empty, single-result, multi-result) 
>>>>> implementations that can be extended as needed.
>>>>>
>>>>>> Julien Vermillard [mailto:[email protected]] wrote:
>>>>>>
>>>>>> Hi,
>>>>>> I implemented some really simple chain for MINA 3 based on a list of
>>>>>> chain processed by a filter chain.
>>>>>>
>>>>>> The implementation is very simple, sounded like a good idea :
>>>>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/or
>>>>>> g/apache/mina/filterchain/DefaultIoFilterChain.java
>>>>>>
>>>>>> But when i started implementing an HTTP codec  I started to see the
>>>>>> real design issues.
>>>>>> The problem is when you need to produce more than one object during a
>>>>>> filter processing, like when you find more than one PDU in a
>>>>>> ByteBuffer.
>>>>>>
>>>>>> We could change IoFilter method :
>>>>>>   Object messageReceived(IoSession session, Object message);
>>>>>> To :
>>>>>>   List<Object> messageReceived(IoSession session, Object message);
>>>>>>
>>>>>> But starting to use collection here sound like an overkill and not
>>>>>> really a nice idea if we want to keep the memory usage low enough.
>>>>>>
>>>>>> So I'm scraping the current implementation, I'm going to try something
>>>>>> else suggested by Emmanuel :
>>>>>> When a filter want to call the next filter, he ask it to the filter
>>>>>> controller (aka the FilterChain). Let's see if it's going somewhere
>>>>>> this time ;)
>>>>>>
>>>>>> Julien
>>>>
>>
>>
>

Reply via email to