mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel LŽcharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Which filters should we keep ?
Date Fri, 08 Jan 2010 16:25:06 GMT
I was also thinking we should add some more filters like :
- a XML filter
- a JSON filter
- a HTTP Filter

assuming that there is no reason to consider them as just protocol 
codec. We could implement them as simple filters, without the whole 
ProtocolCodec mechanism callback et all)


Ashish a écrit :
> On Fri, Jan 8, 2010 at 7:33 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>   
>> Hi guys,
>>
>> in MINA 2, we have many different filters, and I'm not sure we need all of
>> hem. Here is the list :
>>
>> o NoopFilter : probably useless...
>> o ReferenceCountingFilter : Used to count the number of FilterChain we have
>> (ie, the number of session, somehow). Does not seems to be usefull...
>> o SessionAttributeInitializingFilter : Used to inject some default
>> attributes in the session when it's created. Same : probably superfluous
>> o FileRegionWriteFilter : Converts FileRegion to IoBuffer. Not convinced
>> about the interest of such a filter ...
>> o StreamWriteFilter : I do think that it's not the Filter purpose to handle
>> the messages that are to be written. We should instead define an interface
>> for messages that allow the system to write them, whatever the container
>> used.
>> o ProfilerTimerFilter : Shouldn't it be a part of the core system, in
>> coordination with JMX ? When using a filter to do some timing, we lose a
>> part of the action, as we have some processing bing done before the filter
>> is called...
>> o SslFilter : I really think it shuld not be a filter, but a part of the
>> network layer. You negociate SSL first, then you accept incoming messages.
>> o RequestResponseFilter : Due to the total lack of doco ( cf "TODO Add
>> documentation"), it's difficult to say anything about this Filte. Maybe by
>> reading http://issues.apache.org/jira/browse/DIRMINA-92?
>> o BlacklistFilter : Supposely block IPs. Uses a List internally, most
>> certinly suboptimal. Probably useful to have.
>> o BufferedWriteFilter : Useful ? Not sure... probably better to disable
>> Naggle Algorithm and let the underlying network layer dealing with this. Not
>> sure...
>> o MdcInjectionFilter : Useful, definitively
>> o ConnectionThrottleFilter : Useful.
>> o ErrorGeneratingFilter : Was supposed to be designed for tests. Not sure
>> it's useful.
>> o ExecutorFilter : Mandatory.
>> o KeepAliveFilter : Never used it, but I think it can be useful.
>> o LoggingFilter : I'm really not convinced it's a good to have filter.
>> People can define such a Filter using their prefered logging system so
>> easily, I don't see the intrest to have such a filter in core...
>> o ProtocolCodecFilter : Must have, but needs a lot of refactoring.
>> o ProxyFilter : Let's keep it. I don't like its name, because I'm not sure
>> it's explaining exactly what his filter is doing, but I'm also probably not
>> smart enough :)
>> o CompressionFilter : Must have !
>> o WriteRequestFilter : I don't really understand the need fo such a
>> filter... But I have not analyzed it in detail. Waiting for insights
>>
>> That pretty much it for MINA 2. So far, I think we can restreint the list of
>> usful filters to :
>> - BlacklistFilter
>> - MdcInjectionFilter
>> - ConnectionThrottleFilter
>> - ExecutorFilter
>> - KeepAliveFilter
>> - ProtocolCodecFilter
>> - ProxyFilter
>> - CompressionFilter
>>
>> wdyt ?
>>     
>
> Agree on the list. Though I think LoggingFilter is still useful. Its
> easy to implement one, but we have something available, it can be used
> out of the box.
>
> I did some POC related to RequestResponse filter, but didn't made much
> of a progress. I think the functionality can be achieved in a simpler
> way. Will give another shot at trying to get the crux out of it.
>
> Lets keep the list simple, and we can add to it later :-)
>
>   
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.nextury.com
>>
>>
>>
>>     
>
>
>
>   


Mime
View raw message