[MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

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/org/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

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 19, 2011, at 4:53 PM, Emmanuel Lecharny wrote:

> On 8/19/11 2:29 PM, Alan D. Cabrera wrote:
>> On Aug 19, 2011, at 5:16 AM, Emmanuel Lecharny wrote:
>> 
>>> On 8/19/11 1:55 PM, Alan D. Cabrera wrote:
>>>> On Aug 19, 2011, at 4:16 AM, Julien Vermillard 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/org/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 ;)
>>>> I ran into a different scenario that dictated the same result.  For me, often times when a message is sent or received no message is passed on so my protocol had to always return a null.  This always seemed awkward to me.  Also, then that dictated that I had to check for nulls in the framework, also not so good.
>>>> 
>>>> Take a look at my class org.apache.mina.link.UpState to see what I mean.
>>> We should not compare filters and pipes. Think about the whole mechanism as if it was a state machine, because it is. The only relation between two states are those dicatetd by the transition we allow. We don't transite from one state to another one randomly, so are the data passed from one state to another : they are well known by both the initial and the final states.
>> I'm not sure that I'm following.  What is this data that you speak of?
> 
> Let me clarify my thought : I'm talking about any data transiting from one filter to another. If it's from the socket to the first filter, then it's a ByteBuffer. If it's between the decoder and the Handler, then it's a protocol message. Etc.
>> 
>>> We should then make no general presumption about the received and sent data. If one state does not require anything, fine : the caller will know it. OTOH, if we can have multiple data to send to the next state, then we just have to loop and call as many times the next step as necessary.
>> I'm not sure that I'm following.  Who is the caller and why does he need to know all this?
> 
> Simply because the kind of data the receiver will process has to be a data it *can* handle. A decoder is supposed to receive some bytes and transform them to a message. But we can also imagine a 2 layers decoder, and then the second decoder will expect a message, not some bytes.
> 
> One example : in LDAP, we received PDU, which contains TLVs (Type/length/value). Then we transform those TLVs into LDAP message.
> The first decoder will transform bytes to TLVs;
> The second decoder will transform the TLVs to LDAP messages (searchRequest, etc);
> 
> Here, the second decoder won't be able to do anything if it receives some ByteBuffer, so the caller (the first decoder) *must* know what the second decoder will accept, otherwise you'll get some nasty exception.
> 
> Is it clearer?

Yes, filters in a chain must pass messages of a known type between themselves.  There's the added dimension of endpoint cardinality, which this thread discusses, of zero, one, many that can occur on both ends of a link in the chain.

> PS : That's the problem when both of us are not english fluent... When I write a mail (a message), I'm losing some context, and you can't decode exactly what I had in mind when I wrote it. Sorry for that :/

No worries.  I, as an American, struggle to keep my english fluent as well.  ;)



Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/19/11 2:29 PM, Alan D. Cabrera wrote:
> On Aug 19, 2011, at 5:16 AM, Emmanuel Lecharny wrote:
>
>> On 8/19/11 1:55 PM, Alan D. Cabrera wrote:
>>> On Aug 19, 2011, at 4:16 AM, Julien Vermillard 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/org/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 ;)
>>> I ran into a different scenario that dictated the same result.  For me, often times when a message is sent or received no message is passed on so my protocol had to always return a null.  This always seemed awkward to me.  Also, then that dictated that I had to check for nulls in the framework, also not so good.
>>>
>>> Take a look at my class org.apache.mina.link.UpState to see what I mean.
>> We should not compare filters and pipes. Think about the whole mechanism as if it was a state machine, because it is. The only relation between two states are those dicatetd by the transition we allow. We don't transite from one state to another one randomly, so are the data passed from one state to another : they are well known by both the initial and the final states.
> I'm not sure that I'm following.  What is this data that you speak of?

Let me clarify my thought : I'm talking about any data transiting from 
one filter to another. If it's from the socket to the first filter, then 
it's a ByteBuffer. If it's between the decoder and the Handler, then 
it's a protocol message. Etc.
>
>> We should then make no general presumption about the received and sent data. If one state does not require anything, fine : the caller will know it. OTOH, if we can have multiple data to send to the next state, then we just have to loop and call as many times the next step as necessary.
> I'm not sure that I'm following.  Who is the caller and why does he need to know all this?

Simply because the kind of data the receiver will process has to be a 
data it *can* handle. A decoder is supposed to receive some bytes and 
transform them to a message. But we can also imagine a 2 layers decoder, 
and then the second decoder will expect a message, not some bytes.

One example : in LDAP, we received PDU, which contains TLVs 
(Type/length/value). Then we transform those TLVs into LDAP message.
The first decoder will transform bytes to TLVs;
The second decoder will transform the TLVs to LDAP messages 
(searchRequest, etc);

Here, the second decoder won't be able to do anything if it receives 
some ByteBuffer, so the caller (the first decoder) *must* know what the 
second decoder will accept, otherwise you'll get some nasty exception.

Is it clearer?


PS : That's the problem when both of us are not english fluent... When I 
write a mail (a message), I'm losing some context, and you can't decode 
exactly what I had in mind when I wrote it. Sorry for that :/


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 19, 2011, at 5:16 AM, Emmanuel Lecharny wrote:

> On 8/19/11 1:55 PM, Alan D. Cabrera wrote:
>> On Aug 19, 2011, at 4:16 AM, Julien Vermillard 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/org/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 ;)
>> I ran into a different scenario that dictated the same result.  For me, often times when a message is sent or received no message is passed on so my protocol had to always return a null.  This always seemed awkward to me.  Also, then that dictated that I had to check for nulls in the framework, also not so good.
>> 
>> Take a look at my class org.apache.mina.link.UpState to see what I mean.
> 
> We should not compare filters and pipes. Think about the whole mechanism as if it was a state machine, because it is. The only relation between two states are those dicatetd by the transition we allow. We don't transite from one state to another one randomly, so are the data passed from one state to another : they are well known by both the initial and the final states.

I'm not sure that I'm following.  What is this data that you speak of?

> We should then make no general presumption about the received and sent data. If one state does not require anything, fine : the caller will know it. OTOH, if we can have multiple data to send to the next state, then we just have to loop and call as many times the next step as necessary.

I'm not sure that I'm following.  Who is the caller and why does he need to know all this?


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/19/11 1:55 PM, Alan D. Cabrera wrote:
> On Aug 19, 2011, at 4:16 AM, Julien Vermillard 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/org/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 ;)
> I ran into a different scenario that dictated the same result.  For me, often times when a message is sent or received no message is passed on so my protocol had to always return a null.  This always seemed awkward to me.  Also, then that dictated that I had to check for nulls in the framework, also not so good.
>
> Take a look at my class org.apache.mina.link.UpState to see what I mean.

We should not compare filters and pipes. Think about the whole mechanism 
as if it was a state machine, because it is. The only relation between 
two states are those dicatetd by the transition we allow. We don't 
transite from one state to another one randomly, so are the data passed 
from one state to another : they are well known by both the initial and 
the final states.

We should then make no general presumption about the received and sent 
data. If one state does not require anything, fine : the caller will 
know it. OTOH, if we can have multiple data to send to the next state, 
then we just have to loop and call as many times the next step as necessary.

At least, this is my vision...


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 19, 2011, at 4:16 AM, Julien Vermillard 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/org/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 ;)

I ran into a different scenario that dictated the same result.  For me, often times when a message is sent or received no message is passed on so my protocol had to always return a null.  This always seemed awkward to me.  Also, then that dictated that I had to check for nulls in the framework, also not so good.

Take a look at my class org.apache.mina.link.UpState to see what I mean.


Regards,
Alan

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 20, 2011, at 4:32 AM, Edouard De Oliveira wrote:

> We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ? maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)

There's been a fair bit of discussion on this before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both ends is very hard and dynamic chains make it even more difficult.  APIs should promote good practices

With that said, look how complicated the implementation gets below.

Just my 2 cents.


Regards,
Alan

> 
> A copy on write strategy would improve memory footprint. So when would we copy the chain ? when some change happens : add/remove filter 
> a chain controller could associate to the session it's alternative chain or use the default one.
> 
> So now what about threads coming into play ? using threadlocal seems a good idea Em
> 
> So to resume 
> - copy when necessary
> - custom chain should be searched in the following places : threadlocal -> session -> default chain of the controller
> 
> ChainController.getChain() will hide this whole complexity providing flexibility and efficiency wdyt ? 
>  
> Cordialement, Regards,
> -Edouard De Oliveira-
> ________________________________
> De : Emmanuel Lecharny <el...@gmail.com>
> À : dev@mina.apache.org
> Envoyé le : Samedi 20 Août 2011 9h29
> Objet : Re: [MINA 3.0] filter chains
> 
> On 8/20/11 8:49 AM, Julien Vermillard 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.
> 
> The filter chain is copied into the session (at least, it was what was 
> done for MINA 2). Assuming that two different sessions might use two 
> different chains, and assumng that the chain might be dynamically 
> changed, it makes sense to do this copy.
> 
> Now, if we can split the session (using an executor for instance), then 
> the chain must be copied. It would make sense to store the chain into a 
> ThreadLocal variable instead of storing it into a session object.
>> 
>> Julien
>> 
>> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>> 
> 
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com

Re: Re : [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/20/11 1:32 PM, Edouard De Oliveira wrote:
> We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ?
Yes. But SSL should not be handled by a Filter, IMO.

Now, TLS is what we should consider, but it's much more a negociation 
between the client and the application.


> maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)
Again, if there is a possible negotiation, then it's already described 
by the protocol, and there is nothing we can't do with a FSM. No need to 
add dynamically a filter in the chain, and no need to copy the chain in 
most of the case.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Re : Re : [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Fri, Aug 26, 2011 at 1:23 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 8/26/11 1:14 PM, Julien Vermillard wrote:
>>
>> On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
>> <do...@yahoo.fr>  wrote:
>>>
>>> On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
>>>
>>> <do...@yahoo.fr>  wrote:
>>>>
>>>> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>>>>
>>>>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>>>>
>>>>>
>>>>>> But i'm feeling more and more confused by the fsm need : as you said
>>>>>> some management bits in the session can switch on/off some filters why do we
>>>>>> want to complicate the coder 's life using a two state FSM (in the case of
>>>>>> multiple filters it would generate  a much more complicated FSM that the
>>>>>> coder would have to describe with code ... better ?) ?
>>>>>>
>>>>>> Do you want the fsm to control the flow between filters (state=filter
>>>>>> ?) or do you want your fsm to control if a filter is active ?
>>>>>
>>>>> There's no reason why one could not have a chain of FSMs.  You get the
>>>>> exact same behavior with less framework code.
>>>>> The reason why MINA 1 and 2 has a chain is unclear. One possible
>>>>> explainaition is that MINA was supposed to implement the SEDA>architecture
>>>>> (each filter communicate with the next filter using a queue, and as this
>>>>> architecture is supposed to spread filters on more than>one computer, then
>>>>> it's easier to implement it using a chain. Well, that's my perception. One
>>>>> other reason was the lack of vision about the>possible use cases. 6 years in
>>>>> restrospect, I do think that this need never surfaced...
>>>>
>>>> With the growing of the base code it's easier just by looking at what
>>>> exists to find some use case one would not have though of at this time
>>>>
>>>>> The more I think about this problem, the more I think that FSM is the
>>>>> way to go :
>>>>> - we don't add filters dynamically on a created session
>>>>
>>>>> - we *always* know which filter we will call whatever state we are :
>>>>> it's a protocol we are handling, it's well defined !
>>>>
>>>> +1 : it's just that it will require much more preliminary toughts to
>>>> start coding a server ->  that's our good practices promoting thing
>>>>
>>>>> - debugging will be easier
>>>>
>>>> i won't be so categorical about this as whatever graph type you use to
>>>> describe your 'chain' it will still be session/data dependent
>>>>
>>>>> - we won't have to use some strange Mutiplexer filter in order to call
>>>>> one filter or another depending on the message we are dealing with,
>>>>> like>it's currently the case in MINA 2
>>>>
>>>> not so strange as it is a well known design pattern (Command Pattern)
>>>>
>>>>> - coding a protocol will be easier
>>>>
>>>> we have to make basic servers easier (or as easy as before) too
>>>>
>>>>> - we can define @ to declare the FSM, making the developper's life
>>>>> easier (an idea that needs to be developed...)
>>>>> i was also planning on some @ (like @unique to limit the presence of a
>>>>> filter in the chain or some more generic one that would provide the name and
>>>>> the unicity of the filter for Mina 2 obviously)
>>>>> for mina 3 i indeed was wondering if somehow we could use @ to prevent
>>>>> bloated FSM declaration code and found this interesting article>which could
>>>>> be a good base to start with :
>>>>>
>>>>> http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>>>>
>>>> You can find a fast hack at the following pastebin url which shows how i
>>>> changed the original code of the article to add data dependent transitions :
>>>> http://pastebin.com/CjXjJ2Q1
>>>>
>>>>
>>>>> Do we all agree on that ?
>>>>> There's lot of momentum on this solution so it should be given at least
>>>>> a try obviously
>>>>
>>>> +1
>>>> it's hard for me to figure if it's going to be the solution witout a
>>>> more complex example implementation
>>>
>>> it's far from being an implementation it's just a basic poc that a fsm
>>> can be built with @
>>>
>>>
>> I modified the API to remove IoFilterChain. Now you are supposed to
>> give a list of filter to the service before starting it :
>>
>> // create the fitler chain for this service
>> List<IoFilter>  filters = new ArrayList<IoFilter>();
>> filters.add(new LoggingFilter("byte log filter"));
>> filters.add(new MyCodecFilter());
>> filters.add(new LoggingFilter("pojo log filter"));
>> filters.add(newMyProtocolLogicFilter());
>>
>> acceptor.setFilters(filters);
>
> I would like to have something like :
>
> acceptor.addFilters(
>    new LoggingFilter("byte log filter"),
>    new MyCodecFilter(),
>    new LoggingFilter("pojo log filter"),
>    newMyProtocolLogicFilter() )
>
> which is easy as soon as we have a Acceptor.addFilters( Filter... filters )
> method. (ellipsis notation is really very comfy)
>
> thoughts ?
>
> Otherwise, I'm fine with your approach.
>
Ok, I'll change it for varargs

Re: Re : Re : [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 1:14 PM, Julien Vermillard wrote:
> On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
> <do...@yahoo.fr>  wrote:
>> On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
>>
>> <do...@yahoo.fr>  wrote:
>>>
>>> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>>>
>>>>
>>>>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>>>>>
>>>>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
>>>> There's no reason why one could not have a chain of FSMs.  You get the exact same behavior with less framework code.
>>>> The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA>architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than>one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the>possible use cases. 6 years in restrospect, I do think that this need never surfaced...
>>> With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time
>>>
>>>> The more I think about this problem, the more I think that FSM is the way to go :
>>>> - we don't add filters dynamically on a created session
>>>
>>>> - we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
>>> +1 : it's just that it will require much more preliminary toughts to start coding a server ->  that's our good practices promoting thing
>>>
>>>> - debugging will be easier
>>> i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent
>>>
>>>> - we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like>it's currently the case in MINA 2
>>> not so strange as it is a well known design pattern (Command Pattern)
>>>
>>>> - coding a protocol will be easier
>>> we have to make basic servers easier (or as easy as before) too
>>>
>>>> - we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)
>>>> i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)
>>>> for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article>which could be a good base to start with :
>>>> http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>>>
>>> You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
>>> http://pastebin.com/CjXjJ2Q1
>>>
>>>
>>>> Do we all agree on that ?
>>>> There's lot of momentum on this solution so it should be given at least a try obviously
>>> +1
>>> it's hard for me to figure if it's going to be the solution witout a
>>> more complex example implementation
>>
>> it's far from being an implementation it's just a basic poc that a fsm can be built with @
>>
>>
> I modified the API to remove IoFilterChain. Now you are supposed to
> give a list of filter to the service before starting it :
>
> // create the fitler chain for this service
> List<IoFilter>  filters = new ArrayList<IoFilter>();
> filters.add(new LoggingFilter("byte log filter"));
> filters.add(new MyCodecFilter());
> filters.add(new LoggingFilter("pojo log filter"));
> filters.add(newMyProtocolLogicFilter());
>
> acceptor.setFilters(filters);

I would like to have something like :

acceptor.addFilters(
     new LoggingFilter("byte log filter"),
     new MyCodecFilter(),
     new LoggingFilter("pojo log filter"),
     newMyProtocolLogicFilter() )

which is easy as soon as we have a Acceptor.addFilters( Filter... 
filters ) method. (ellipsis notation is really very comfy)

thoughts ?

Otherwise, I'm fine with your approach.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

[Alex Karasulu <ak...@apache.org>]

On Fri, Aug 26, 2011 at 9:47 PM, Alan D. Cabrera <li...@toolazydogs.com>wrote:

>
> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>
> > On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
> >> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
> >> What I have in mind is much more something like :
> >>
> >> void messageReceived( context )
> >> {
> >>    ... // do something, updating the context, eventually setting a
> status
> >>   controller.callNextFilter( context, currentFilter );
> >>    ... // do something after the call
> >> }
> >>
> >> and in controller :
> >> void callNextFilter( Context context, Filter currentFilter )
> >> {
> >>    Status status = context.getStatus();
> >>    Map<Status, Filter>  map = fsmMap.get( currentFilter );
> >>    Filter nextFilter = map.get( status );
> >>
> >>    nextFilter.messageReceived( context );
> >> }
> >> This strikes me as pretty complex, jmho.  Also, I don't like the idea of
> forcing the filter to call the controller.callNextFilter() to make things
> work.
> > the alternative would be something like :
> >
> > void messageReceived( context )
> > {
> >   ... // do something, updating the context, eventually setting a status
> >  fsmMap.get( this ).get( status ).messageReceived( context );
> >   ... // do something after the call
> > }
> >
> > No controller, but a long list of chained call.
>
> But we're still forcing the filter to participate in things that really
> should be the domain of the controller not the filter.
>
> With that said I think that an FSM where we have, here letters are filters:
>
> [outside filter] -> {A -> [state change decides to send to] -> B ->  [state
> change decides to send to]  -> C} -> [outside filter]
>
> is very confusing.  What protocol would require that?  Just an honest
> question; one does not come to my mind atm.
>
> > Also the fsmMap must be known by the current filter.
> >> Look at my implementation of org.apache.mina.link.DownState as an
> example.  This framework does not require a call to a controller for the
> whole thing to work.  This filter merely focuses on its task at hand and
> implementation does not leak as much into its message received method.
> >
> > Ok, I'll give it a look.
> >>
> >>> The controller will decide which filter must be called depending on the
> context status.
> >>>
> >>> (Note that the controller should also decide which message to call, for
> instance, it can decide that it has to call a messageReceived() because it's
> caller was processing a messageReceived())
> >> I feel that, for the most part, we all have been doing a lot of
> discussions without any mock implementations of real protocols to help us
> gauge our API decisions.
> > I'm "lucky" enough to have played with MINA for more than 5 years, facing
> many differents kind of protocol based on it, plus having answered many of
> MINA user's questions regarding how to implement many different kind of
> protocol.
> >
> > Trust me on that, when I'm thinking about the new API, I always have in
> mind the different "real world" protocols we have to deal with. That
> includes :
> > - obviously LDAP protocol, which is a binary, two layer codec, demuxed
> protocol
> > - NTP based on UDP
> > - Kerberos based on UDP *and* TCP
> > - HTTP, ie newline terminated decoder, a cumulative decoder
> > - a few proprietary protocole implemented using MINA, with fixed size
> data, or LV type PDUs
>
> I think you missed my point.  I am not questioning anyone's expertise in
> the industry.  I am calling out the current modus operandi of the current
> API design process and it's need for real world mockups.
>
> >> Our tendency is to dive into the implementation details and then
> shoehorn protocols into the resultant API.
> > Not exactly my state of mind... I'm more trying to find the best possible
> solution, dealing with many constraints :
> > - ease of use
> > - coverage of the different use cases
> > - memory consumption
> > - ease of debuging
> > - speed
>
> Definitely good points.  We all want this but they speak nothing to the
> process of coming up with an API.  My point is to have concrete examples of
> how the API bits we are proposing would look.  A perfect example is your and
> my ideas of how the FSM should work.  With no concrete mocked up bits to see
> how the two APIs would influence the implementation of a protocol the
> discussion devolves into arguments over aesthetic opinions.
>
> >>  This is why Mina 2 is so bloated and daunting.
> > MINA 2 is bloated for different reasons, and I think I have already
> discussed some of them.
> >
> > One of the most problematic reason is that MINA 2 (and 1) was a one man
> show. This is why I'm really pleased to have those discussion here, even if
> it seems to be a bike-shedding discussion. It is not.
>

+1

I'm glad to see these discussions. They're getting more and more concrete
every day.


>
> Agreed on the last bit.  Anyone who thinks the current discussions about
> the API design are bike shed issues never designed an API.
>
> >>  I'd like to see lots of little sandbox branches where people show what
> protocol implementations would end up looking like for the feature they are
> proposing.  It's a fantastic way to gauge API design differences.
> > I like Julien's approach : designing a working solution, not covering all
> our bases right now, and implement a few existing protocols. Then moving
> forward.
>
> I'm sorry but that seems totally backwards to me.  The API design should be
> the framework from which the working solution evolves.  Starting with the
> implementations could automatically close the doors on useful API features.
>
>
+1

This methodology is a faster version of how MINA 2 evolved: out of need. It
might bind us to constructs that are not that easy to evolve out of as was
the case for MINA 2.

I agree with Alan about mock ups for various protocols because it will show
clearly which approach is cleaner. We can even benchmark performance and
also see if the debugging process is a PITA. It's the comprehensive way to
go. Let's face it the code base is small but getting the API right is hard.
Experimenting with multiple incarnations and implementations will show us
the best path.

-- 
Best Regards,
-- Alex

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 7:54 AM, Emmanuel Lecharny wrote:

> On 8/26/11 4:41 PM, Julien Vermillard wrote:
>> On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabrera<li...@toolazydogs.com>  wrote:
>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>> 
>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>  wrote:
>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>> 
>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>> wrote:
>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>> 
>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>> 
>>>>>>>>> // create the fitler chain for this service
>>>>>>>>> List<IoFilter>    filters = new ArrayList<IoFilter>();
>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>> 
>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>> 
>>>>>>>>> acceptor.bind(...);
>>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>>> 
>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>> 
>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>> 
>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>> 
>>>>>>>> acceptor.setFilters(foo);
>>>>>>>> 
>>>>>>> About the code in the sandbox :
>>>>>>> 
>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>>> right place ?
>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>> 
>>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>>> you have a concrete use case in mind for that ?
>>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>>> would all of this fit into the grand scheme of things?
>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>> 
>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>> : http://s.apache.org/A9W
>>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>>> 
>> I think we need to avoid complex feature like graph. IMHO server in
>> MINA is a codec and an handler 90% of the time. Someone have a use
>> case which could use filter graph with MINA ?
> 
> yes. We use it for LDAP... And we have had some users asking how to manage a decoder for multiple kind of messages.
> 
> This is not something we want just because it's beautiful.
> 
> Now, what about having a controller hidding the internal structure, so that we can switch to a graph later ? IMO, we should not expose the inner data structure, be it a list or a graph. It's the controller's business to deal with that.
> 
> However, we must provide the current state to the controller, it's not enough to provide the current filter.

Look at how things are set up in my sandbox.  The parents and children can have any cardinality, even zero.  The controller should be able to automatically handle all of that.


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lécharny <el...@apache.org>]

On 8/27/11 10:53 AM, Alex Karasulu wrote:
> On Sat, Aug 27, 2011 at 5:35 AM, Emmanuel Lecharny<el...@gmail.com>wrote:
>
>> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>>
>>> On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
>>>
>>>   On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>>>>
>>>>>   On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>>>>> What I have in mind is much more something like :
>>>>>>>
>>>>>>> void messageReceived( context )
>>>>>>> {
>>>>>>>     ... // do something, updating the context, eventually setting a
>>>>>>> status
>>>>>>>    controller.callNextFilter( context, currentFilter );
>>>>>>>     ... // do something after the call
>>>>>>> }
>>>>>>>
>>>>>>> and in controller :
>>>>>>> void callNextFilter( Context context, Filter currentFilter )
>>>>>>> {
>>>>>>>     Status status = context.getStatus();
>>>>>>>     Map<Status, Filter>     map = fsmMap.get( currentFilter );
>>>>>>>     Filter nextFilter = map.get( status );
>>>>>>>
>>>>>>>     nextFilter.messageReceived( context );
>>>>>>> }
>>>>>>> This strikes me as pretty complex, jmho.  Also, I don't like the idea
>>>>>>> of forcing the filter to call the controller.callNextFilter() to make things
>>>>>>> work.
>>>>>>>
>>>>>> the alternative would be something like :
>>>>>>
>>>>>> void messageReceived( context )
>>>>>> {
>>>>>>    ... // do something, updating the context, eventually setting a
>>>>>> status
>>>>>>   fsmMap.get( this ).get( status ).messageReceived( context );
>>>>>>    ... // do something after the call
>>>>>> }
>>>>>>
>>>>>> No controller, but a long list of chained call.
>>>>>>
>>>>> But we're still forcing the filter to participate in things that really
>>>>> should be the domain of the controller not the filter.
>>>>>
>>>> If we delegate the transition to the controller, then we can't have post
>>>> actions... Obviously, not having post actions makes it easier. (Post action
>>>> are really important if we want to do something when we come back from the
>>>> application.)
>>>>
>>> I think we're getting to some interesting bits. Can you provide more exact
>>> detail?
>>>
>> One very simple example, taken from the ProfilerFilter :
>>
>>     @Override
>>     public void messageReceived(NextFilter nextFilter, IoSession session,
>>             Object message) throws Exception {
>>         if (profileMessageReceived) {
>>             long start = timeNow();
>>             nextFilter.messageReceived(**session, message);
>>             long end = timeNow();
>>             messageReceivedTimerWorker.**addNewDuration(end - start);
>>         } else {
>>             nextFilter.messageReceived(**session, message);
>>         }
>>     }
>>
>> If you depend on the controller to call thenext filter, then you have no
>> easy way to compute the time it takes to process the action, as you won't be
>> able to execute the post action.
>>
>> Note that the decoding of multiple messages within one PDU won't be
>> possible either without being able to process post-actions. (see below)
>>
>>   One clear exemple would be a decoder processing a PDU with more than one
>>>> message : you can't anymore loop on the PDU if you delegate the next call to
>>>> the controller.
>>>>
>>> What is the format of this PDU and how is it presented to the FSM, i.e. in
>>> what kind of pieces does it arrive?
>>>
>> You get an array of bytes, containing potentially more than one message.
>> The fact is that you have no way to get a byte array from the socket as soon
>> as a complete message has been received : the socket does not know anything
>> about messages.
>>
>> You just have to assume that the PDU you've got can be :
>> - either a portion of a message, and you have to wait for more bytes in
>> order to produce a message
>> - a full message, once decoded
>> - more than one message you have to send to the handler one by one
>> - some full messages plus a fraction of a message
>>
>>
>>>   With that said I think that an FSM where we have, here letters are
>>>>> filters:
>>>>>
>>>>> [outside filter] ->    {A ->    [state change decides to send to] ->    B
>>>>> ->     [state change decides to send to]  ->    C} ->    [outside filter]
>>>>>
>>>>> is very confusing.  What protocol would require that?  Just an honest
>>>>> question; one does not come to my mind atm.
>>>>>
>>>> all of them :) This is what we currently do in MINA.
>>>>
>>> I think that I am hearing a reply that explains that all the protocols are
>>> implemented in this way.  I'm not hearing an explanation as to why it *must*
>>> be that way.
>>>
>> simply because you can't move to the next filter unless you have
>> transformed what you've got from the previous filter. If we exclude all the
>> utility filters (like the loggers), a filter can only process a certain type
>> of message, and produce another type of message. The chain of filters is
>> dictated by the transformation done at each step. One good example is LDAP
>> processing : in order to decode a LDAP message, you first have to decode the
>> TLVs, then you can decode the messages themselves. A LDAP chain would be
>> something like :
>>
>> [outside filter] ->  (bytes) ->  { TLV decoder filter ->  (TLVs) ->  LDAP
>> decoder filter ->  (LDAPmessages) } ->  [outside filter]
>>
>> (add to this the fact that you may loop on the TLV filter *and* the LDAP
>> filter, plus the fact that you may have to wait for more bytes)
>>
>> Now, it makes *no sense* to exchange the filters. It will simply not work.
>> It's the very same for any protocol we will process with such a mechanism.
>>
>> In other words, the order the filters are executed is not random. It's
>> fixed by design, and does not change (as soon as we have ruled out the
>> possibility to have a dynamic chain).
>>
>>
>> Another way to see this mechanism is that it's a path from one point to
>> another : you may have many different paths, but for a set of bytes, you
>> will always follow the same path. The only way to follow two different paths
>> is when you get two different sets of bytes.
>>
>>
> Emmanuel, thanks for chiming in here on behalf of the ASN.1 based codecs.
> Alan these concepts are very important for us to factor in.
>
> The problem here is that processing in one state of an FSM may alter the
> control flow.
>
> I know we're trying to find the design that leads to the sweetest and
> easiest code for implementing these filters. However it's possible that this
> process of defining protocols may evolve to where protocol implementors feed
> in a state transition matrix and most of the code is generated minus
> customizations supplied for actions to take.
>
> I might be flying in the clouds with this but it might be another one of the
> design constraints added to Emmanuel's list to at least consider.
>
After having thought about FSM all night long, I realize this morning 
that using a FSM and having post processing actions is a bit complex.

Assuming we let the controller deal with the transition from two states, 
then that mean a post action must itself be a State (Filter).

Such a method :

void messageReceived( context )
{
   ... // do something, updating the context, eventually setting a
status
  fsmMap.get( this ).get( status ).messageReceived( context );
   ... // do something after the call
}


would have to be mapped differently :

Filter 1 :

void messageReceived( context )
{
   ... // do something
   // End of the method, the control switch to the next configured filter
}


Filter2 (contain the post action)

void messageReceived( context )
{
   ... // do something, this is a post action
}


then the FSM should describe the following transition :

input ... -> Filter1.messageReceived() ---> handler.messageReceived() 
--> Filter2.messageReceived()

So the post action is called when the handler has processed the message.

IMHO, it's not really convenient...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

[Alex Karasulu <ak...@apache.org>]

On Sat, Aug 27, 2011 at 5:35 AM, Emmanuel Lecharny <el...@gmail.com>wrote:

> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>
>> On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
>>
>>  On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>>>
>>>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>>>
>>>>  On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>>>
>>>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>>>> What I have in mind is much more something like :
>>>>>>
>>>>>> void messageReceived( context )
>>>>>> {
>>>>>>    ... // do something, updating the context, eventually setting a
>>>>>> status
>>>>>>   controller.callNextFilter( context, currentFilter );
>>>>>>    ... // do something after the call
>>>>>> }
>>>>>>
>>>>>> and in controller :
>>>>>> void callNextFilter( Context context, Filter currentFilter )
>>>>>> {
>>>>>>    Status status = context.getStatus();
>>>>>>    Map<Status, Filter>    map = fsmMap.get( currentFilter );
>>>>>>    Filter nextFilter = map.get( status );
>>>>>>
>>>>>>    nextFilter.messageReceived( context );
>>>>>> }
>>>>>> This strikes me as pretty complex, jmho.  Also, I don't like the idea
>>>>>> of forcing the filter to call the controller.callNextFilter() to make things
>>>>>> work.
>>>>>>
>>>>> the alternative would be something like :
>>>>>
>>>>> void messageReceived( context )
>>>>> {
>>>>>   ... // do something, updating the context, eventually setting a
>>>>> status
>>>>>  fsmMap.get( this ).get( status ).messageReceived( context );
>>>>>   ... // do something after the call
>>>>> }
>>>>>
>>>>> No controller, but a long list of chained call.
>>>>>
>>>> But we're still forcing the filter to participate in things that really
>>>> should be the domain of the controller not the filter.
>>>>
>>> If we delegate the transition to the controller, then we can't have post
>>> actions... Obviously, not having post actions makes it easier. (Post action
>>> are really important if we want to do something when we come back from the
>>> application.)
>>>
>> I think we're getting to some interesting bits. Can you provide more exact
>> detail?
>>
>
> One very simple example, taken from the ProfilerFilter :
>
>    @Override
>    public void messageReceived(NextFilter nextFilter, IoSession session,
>            Object message) throws Exception {
>        if (profileMessageReceived) {
>            long start = timeNow();
>            nextFilter.messageReceived(**session, message);
>            long end = timeNow();
>            messageReceivedTimerWorker.**addNewDuration(end - start);
>        } else {
>            nextFilter.messageReceived(**session, message);
>        }
>    }
>
> If you depend on the controller to call thenext filter, then you have no
> easy way to compute the time it takes to process the action, as you won't be
> able to execute the post action.
>
> Note that the decoding of multiple messages within one PDU won't be
> possible either without being able to process post-actions. (see below)
>
>  One clear exemple would be a decoder processing a PDU with more than one
>>> message : you can't anymore loop on the PDU if you delegate the next call to
>>> the controller.
>>>
>> What is the format of this PDU and how is it presented to the FSM, i.e. in
>> what kind of pieces does it arrive?
>>
>
> You get an array of bytes, containing potentially more than one message.
> The fact is that you have no way to get a byte array from the socket as soon
> as a complete message has been received : the socket does not know anything
> about messages.
>
> You just have to assume that the PDU you've got can be :
> - either a portion of a message, and you have to wait for more bytes in
> order to produce a message
> - a full message, once decoded
> - more than one message you have to send to the handler one by one
> - some full messages plus a fraction of a message
>
>
>>  With that said I think that an FSM where we have, here letters are
>>>> filters:
>>>>
>>>> [outside filter] ->   {A ->   [state change decides to send to] ->   B
>>>> ->    [state change decides to send to]  ->   C} ->   [outside filter]
>>>>
>>>> is very confusing.  What protocol would require that?  Just an honest
>>>> question; one does not come to my mind atm.
>>>>
>>> all of them :) This is what we currently do in MINA.
>>>
>> I think that I am hearing a reply that explains that all the protocols are
>> implemented in this way.  I'm not hearing an explanation as to why it *must*
>> be that way.
>>
>
> simply because you can't move to the next filter unless you have
> transformed what you've got from the previous filter. If we exclude all the
> utility filters (like the loggers), a filter can only process a certain type
> of message, and produce another type of message. The chain of filters is
> dictated by the transformation done at each step. One good example is LDAP
> processing : in order to decode a LDAP message, you first have to decode the
> TLVs, then you can decode the messages themselves. A LDAP chain would be
> something like :
>
> [outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP
> decoder filter -> (LDAPmessages) } -> [outside filter]
>
> (add to this the fact that you may loop on the TLV filter *and* the LDAP
> filter, plus the fact that you may have to wait for more bytes)
>
> Now, it makes *no sense* to exchange the filters. It will simply not work.
> It's the very same for any protocol we will process with such a mechanism.
>
> In other words, the order the filters are executed is not random. It's
> fixed by design, and does not change (as soon as we have ruled out the
> possibility to have a dynamic chain).
>
>
> Another way to see this mechanism is that it's a path from one point to
> another : you may have many different paths, but for a set of bytes, you
> will always follow the same path. The only way to follow two different paths
> is when you get two different sets of bytes.
>
>
Emmanuel, thanks for chiming in here on behalf of the ASN.1 based codecs.
Alan these concepts are very important for us to factor in.

The problem here is that processing in one state of an FSM may alter the
control flow.

I know we're trying to find the design that leads to the sweetest and
easiest code for implementing these filters. However it's possible that this
process of defining protocols may evolve to where protocol implementors feed
in a state transition matrix and most of the code is generated minus
customizations supplied for actions to take.

I might be flying in the clouds with this but it might be another one of the
design constraints added to Emmanuel's list to at least consider.

-- 
Best Regards,
-- Alex

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 4:41 PM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabrera<li...@toolazydogs.com>  wrote:
>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>
>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>  wrote:
>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>
>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>   wrote:
>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>
>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>
>>>>>>>> // create the fitler chain for this service
>>>>>>>> List<IoFilter>    filters = new ArrayList<IoFilter>();
>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>
>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>
>>>>>>>> acceptor.bind(...);
>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>>
>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>
>>>>>>> IoFilter foo = new FooFilter();
>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>> IoFilter log = new LogFilter();
>>>>>>>
>>>>>>> link.addLinkStateListener(foo);
>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>> linkParentWithChild(link, checksum);
>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>
>>>>>>> acceptor.setFilters(foo);
>>>>>>>
>>>>>> About the code in the sandbox :
>>>>>>
>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>> right place ?
>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>
>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>> you have a concrete use case in mind for that ?
>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>> would all of this fit into the grand scheme of things?
>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>
>>> Well if it's just for demuxing I proposed few mails ago this solution
>>> : http://s.apache.org/A9W
>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>>
> I think we need to avoid complex feature like graph. IMHO server in
> MINA is a codec and an handler 90% of the time. Someone have a use
> case which could use filter graph with MINA ?

yes. We use it for LDAP... And we have had some users asking how to 
manage a decoder for multiple kind of messages.

This is not something we want just because it's beautiful.

Now, what about having a controller hidding the internal structure, so 
that we can switch to a graph later ? IMO, we should not expose the 
inner data structure, be it a list or a graph. It's the controller's 
business to deal with that.

However, we must provide the current state to the controller, it's not 
enough to provide the current filter.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re : Re : [MINA 3.0] filter chains

[Edouard De Oliveira <do...@yahoo.fr>]

De : Emmanuel Lécharny <el...@apache.org>
À : dev@mina.apache.org
Cc : 
Envoyé le : Vendredi 26 Août 2011 18h10
Objet : Re: Re : [MINA 3.0] filter chains

On 8/26/11 6:02 PM, Edouard De Oliveira wrote:
> De : Emmanuel Lecharny<el...@gmail.com>
> 
> 
> The theory sounds ok but it also seems that Alan has something much more (too ?) complex in mind for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?

>DAG is just a restricted form of a FSM. It just forbid a loop, which is exactly what we need in our case (why would we cycle on a filter we >already went through ?)


The concept is a basic it's just the acronym that may not be known ...

-- Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Re : [MINA 3.0] filter chains

[Emmanuel Lécharny <el...@apache.org>]

On 8/26/11 6:02 PM, Edouard De Oliveira wrote:
> De : Emmanuel Lecharny<el...@gmail.com>
>
>
> The theory sounds ok but it also seems that Alan has something much more (too ?) complex in mind 
> for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?

DAG is just a restricted form of a FSM. It just forbid a loop, which is 
exactly what we need in our case (why would we cycle on a filter we 
already went through ?)


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 9:02 AM, Edouard De Oliveira wrote:

> De : Emmanuel Lecharny <el...@gmail.com>
> 
> À : dev@mina.apache.org
> Envoyé le : Vendredi 26 Août 2011 17h12
> Objet : Re: [MINA 3.0] filter chains
> 
> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>> 
>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>> 
>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>   wrote:
>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>> 
>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>>>    wrote:
>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>> 
>>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>> 
>>>>>>>>>> // create the fitler chain for this service
>>>>>>>>>> List<IoFilter>    filters = new ArrayList<IoFilter>();
>>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>> 
>>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>> 
>>>>>>>>>> acceptor.bind(...);
>>>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>>>> 
>>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>>> 
>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>> 
>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>> 
>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>> 
>>>>>>>> About the code in the sandbox :
>>>>>>>> 
>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>>>> right place ?
>>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>> 
>>>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>>>> you have a concrete use case in mind for that ?
>>>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>>>> would all of this fit into the grand scheme of things?
>>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>> 
>>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>>> : http://s.apache.org/A9W
>>>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>>> I do agree. The proposed solution on http://s.apache.org/A9W is what we currently have, and it's tedious to manage.
>>> 
>>> It would be way better to be able to let the controler call the next filter based on an evaluation method based on the current state.
>>> 
>>> 
>>> Now, the question is : how do the controller knows which filter to call next ? It must have the current state, and it must be able to make the connection.
>>> 
>>> For instance, let's say that from filter F we can switch to either filter G or filter H, depending on the state we transit to in F.
>>> 
>>> F --(state1)-->  G
>>> or
>>> F --(state2)-->  H
>>> 
>>> That means the controller has a map { (F, state1, G), (F, state2, H)} somewhere. State should be passed to the controller too :
>>> 
>>> ...
>>> controller.nextFilter( newState );
>>> ...
>>> 
>>> Pretty theorical at this point... I'm sorry not to have a lot of time to code this, I do realize that for you guys implementing ideas it's a PITA...
>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>> 
>> ->  [FSM1] ->  [Filter] ->  [FSM2] ->  [Filter]
>> 
>> Inside the FSM there could be chains, but there would be one chain per state.
> Not sure I grok what you say here. There is more than one state, and 
> from each state, you may have more than one transition.
> 
> Maybe it's just a problem of vocabulary...
> 
> <theory>
> In a FSM, you transit from Si to Sj, following a transition Ta, which 
> depends on a context. You may also transit to a state Sk, following a 
> different transition Tb, if the context is different.
> 
> Selection the transition to follow is all about knowing what's the 
> context is, and in my sample, this was what I call the 'state', which 
> was most certainly an error, as it's clearly a transition. I should have 
> wrote :
> 
> F --(transition1)-->  G
> or
> F --(transition2)-->  H
> 
> where F, G, H are filters (ore "states")
> 
> are we on the same page ?
> 
> </theory>
> 
> 
> The theory sounds ok but it also seems that Alan has something much more (too ?) complex in mind 
> for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?

Yes, this is the definition of a DAG but I am using it to precisely state the characteristics of the graph.  Simply put, no circularities.

A tree is a DAG.  MUX/DEMUX is a DAG.

As I mentioned, it's a simple straightforward concept that every programmer should know.  The benefit is that it dramatically keeps things simpler by removing circularities.


Regards,
Alan

Re : [MINA 3.0] filter chains

[Edouard De Oliveira <do...@yahoo.fr>]

De : Emmanuel Lecharny <el...@gmail.com>

À : dev@mina.apache.org
Envoyé le : Vendredi 26 Août 2011 17h12
Objet : Re: [MINA 3.0] filter chains

On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>
>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>   wrote:
>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>
>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>>   wrote:
>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>
>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>
>>>>>>>>> // create the fitler chain for this service
>>>>>>>>> List<IoFilter>    filters = new ArrayList<IoFilter>();
>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>
>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>
>>>>>>>>> acceptor.bind(...);
>>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>>>
>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>>
>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>
>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>
>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>
>>>>>>> About the code in the sandbox :
>>>>>>>
>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>>> right place ?
>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>
>>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>>> you have a concrete use case in mind for that ?
>>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>>> would all of this fit into the grand scheme of things?
>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>
>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>> : http://s.apache.org/A9W
>>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>> I do agree. The proposed solution on http://s.apache.org/A9W is what we currently have, and it's tedious to manage.
>>
>> It would be way better to be able to let the controler call the next filter based on an evaluation method based on the current state.
>>
>>
>> Now, the question is : how do the controller knows which filter to call next ? It must have the current state, and it must be able to make the connection.
>>
>> For instance, let's say that from filter F we can switch to either filter G or filter H, depending on the state we transit to in F.
>>
>> F --(state1)-->  G
>> or
>> F --(state2)-->  H
>>
>> That means the controller has a map { (F, state1, G), (F, state2, H)} somewhere. State should be passed to the controller too :
>>
>> ...
>> controller.nextFilter( newState );
>> ...
>>
>> Pretty theorical at this point... I'm sorry not to have a lot of time to code this, I do realize that for you guys implementing ideas it's a PITA...
> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>
> ->  [FSM1] ->  [Filter] ->  [FSM2] ->  [Filter]
>
> Inside the FSM there could be chains, but there would be one chain per state.
Not sure I grok what you say here. There is more than one state, and 
from each state, you may have more than one transition.

Maybe it's just a problem of vocabulary...

<theory>
In a FSM, you transit from Si to Sj, following a transition Ta, which 
depends on a context. You may also transit to a state Sk, following a 
different transition Tb, if the context is different.

Selection the transition to follow is all about knowing what's the 
context is, and in my sample, this was what I call the 'state', which 
was most certainly an error, as it's clearly a transition. I should have 
wrote :

F --(transition1)-->  G
or
F --(transition2)-->  H

where F, G, H are filters (ore "states")

are we on the same page ?

</theory>


The theory sounds ok but it also seems that Alan has something much more (too ?) complex in mind 
for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/28/11 8:09 PM, Alan D. Cabrera wrote:
> On Aug 28, 2011, at 10:44 AM, Emmanuel Lecharny wrote:
>
>> On 8/28/11 6:27 PM, Alan D. Cabrera wrote:
>>> On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:
>>>
>>> I took a bit of time to start fleshing out an LDAP server and now know why we've been back and forth so often.  You are using an FSM to parse messages and I am using FSMs to implement network protocols.
>> We are using a FSM to decode the LDAP messages, but this is an orthogonal concern here.
> Are you restating what I have just said?  I fear I may be missing some point.

I just say that the fact the LDAP decoder is using a FSM is irrelevant 
to the MINA chain"s discussion.
>
>> The problem we had with MINA is that we would have prefered to have two decoder filters : one for the TLVs and another one for the LDAP messages. It was not possible when we first created this decoder.
> In ASN.1 this may not be possible given the different encoding rules.  Some of which force the "merging" of TLV and message parsing, i.e. some rules allow for the eliding of tags.  Not sure if that is relevant to LDAP which may force the use of BER.
Of course, TLVs are only important when decoding BER/CER encoded ASN/1. 
You can't decode PER encoded ASN.1 using this technic. LDAP mandates 
that BER is used.

>
>> Also we have to use a demux at the end, and it's a PITA. Would we be able to use a FSM to implment the LDAP protocol as a whole, we would be more than happy.
> This is an interesting statement.  Can you provide more detail?

Sure : the LDAP decoder is actually managed in one single filter. The 
problem is that we have to decode the TLVs first, before being able to 
determinate which kind of message we are dealing with. For instance, a 
Search request always starts with the following bytes (where NN is an 
encoded integer, and LL is the Value length ):
0x30 LL 0x02 0x0[1..4] NN 0x63 LL ...

A Bind request starts with the following bytes :

0x30 LL 0x02 0x0[1..4] NN 0x60 LL ...

As you can see, until we have decoded the third TLV, we have no idea 
what kind of LDAP message we are dealing with.

Now, once the message has been decoded, we transmit it to the next 
Filter which calls the right handler, depending on the message. That 
means the Handler extends DemuxingIoHandler, which requires that you 
configure a Map associating a message type with a dedicated handler.

If we were using a FSM instead, then the message would just have to call 
the right filter, the one which redirect to the associated handler

>
>>>   Two totally different things.  I think we should think about this for a bit but I will quickly state that I think the way to handle this is to have something not unlike an SSL engine inside a filter;
>> SSL as a filter was a big mistake, IMHO.
> It may have no industry use but I think can serve as a nice POC for using a parsing engine inside an FSM, a pattern that I think may be applicable to LDAP messages.

The very problem of the SSL filter is that it *must* be placed in the 
first position in the chain, because it initiates a dialog with the 
client in order to establish the encrypted session.

At some point, it can probably be managed by a FSM, too.

Regarding using a generic FSM to decode LDAP messages, well, that's a 
very interesting idea. We even discussed a while back about using the 
MINA's stateMachine project, but w never went any further, due to lack 
of time.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 28, 2011, at 10:44 AM, Emmanuel Lecharny wrote:

> On 8/28/11 6:27 PM, Alan D. Cabrera wrote:
>> On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:
>> 
>> I took a bit of time to start fleshing out an LDAP server and now know why we've been back and forth so often.  You are using an FSM to parse messages and I am using FSMs to implement network protocols.
> We are using a FSM to decode the LDAP messages, but this is an orthogonal concern here.

Are you restating what I have just said?  I fear I may be missing some point.

> The problem we had with MINA is that we would have prefered to have two decoder filters : one for the TLVs and another one for the LDAP messages. It was not possible when we first created this decoder.

In ASN.1 this may not be possible given the different encoding rules.  Some of which force the "merging" of TLV and message parsing, i.e. some rules allow for the eliding of tags.  Not sure if that is relevant to LDAP which may force the use of BER.

> Also we have to use a demux at the end, and it's a PITA. Would we be able to use a FSM to implment the LDAP protocol as a whole, we would be more than happy.

This is an interesting statement.  Can you provide more detail?

>>  Two totally different things.  I think we should think about this for a bit but I will quickly state that I think the way to handle this is to have something not unlike an SSL engine inside a filter;
> SSL as a filter was a big mistake, IMHO.

It may have no industry use but I think can serve as a nice POC for using a parsing engine inside an FSM, a pattern that I think may be applicable to LDAP messages.


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/28/11 6:27 PM, Alan D. Cabrera wrote:
> On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:
>
> I took a bit of time to start fleshing out an LDAP server and now know why we've been back and forth so often.  You are using an FSM to parse messages and I am using FSMs to implement network protocols.
We are using a FSM to decode the LDAP messages, but this is an 
orthogonal concern here.

The problem we had with MINA is that we would have prefered to have two 
decoder filters : one for the TLVs and another one for the LDAP 
messages. It was not possible when we first created this decoder. Also 
we have to use a demux at the end, and it's a PITA. Would we be able to 
use a FSM to implment the LDAP protocol as a whole, we would be more 
than happy.


>   Two totally different things.  I think we should think about this for a bit but I will quickly state that I think the way to handle this is to have something not unlike an SSL engine inside a filter;
SSL as a filter was a big mistake, IMHO.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <ad...@toolazydogs.com>]

On Aug 27, 2011, at 1:51 PM, Alan D. Cabrera wrote:

> 
> On Aug 26, 2011, at 7:35 PM, Emmanuel Lecharny wrote:
> 
>> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>> 
>> simply because you can't move to the next filter unless you have transformed what you've got from the previous filter. If we exclude all the utility filters (like the loggers), a filter can only process a certain type of message, and produce another type of message. The chain of filters is dictated by the transformation done at each step. One good example is LDAP processing : in order to decode a LDAP message, you first have to decode the TLVs, then you can decode the messages themselves. A LDAP chain would be something like :
>> 
>> [outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP decoder filter -> (LDAPmessages) } -> [outside filter]
>> 
>> (add to this the fact that you may loop on the TLV filter *and* the LDAP filter, plus the fact that you may have to wait for more bytes)
>> 
>> Now, it makes *no sense* to exchange the filters. It will simply not work. It's the very same for any protocol we will process with such a mechanism.
>> 
>> In other words, the order the filters are executed is not random. It's fixed by design, and does not change (as soon as we have ruled out the possibility to have a dynamic chain).
>> 
>> 
>> Another way to see this mechanism is that it's a path from one point to another : you may have many different paths, but for a set of bytes, you will always follow the same path. The only way to follow two different paths is when you get two different sets of bytes.
> 
> I'm not sure that this needs to be a single FSM.  Why not
> 
> [outside filter] -> (bytes) -> [TLV decoder filter] -> (TLVs) -> [LDAP decoder filter] -> (LDAPmessages) -> [outside filter]
> 
> I hear "looping" being a justification but it strikes me that using an FSM obfuscates things needlessly as I believe that a simple filter will do.
> 
> Is there some code I can look at to see your above implementation?  I think here is a perfect case for code bits to compare.

I took a bit of time to start fleshing out an LDAP server and now know why we've been back and forth so often.  You are using an FSM to parse messages and I am using FSMs to implement network protocols.  Two totally different things.  I think we should think about this for a bit but I will quickly state that I think the way to handle this is to have something not unlike an SSL engine inside a filter; look at my sloppy sketch that's "evolving" in my sandbox.



Regards,
Alan
 

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 7:35 PM, Emmanuel Lecharny wrote:

> On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
>> 
>>> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>>> 
>>>>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>>>> What I have in mind is much more something like :
>>>>>> 
>>>>>> void messageReceived( context )
>>>>>> {
>>>>>>    ... // do something, updating the context, eventually setting a status
>>>>>>   controller.callNextFilter( context, currentFilter );
>>>>>>    ... // do something after the call
>>>>>> }
>>>>>> 
>>>>>> and in controller :
>>>>>> void callNextFilter( Context context, Filter currentFilter )
>>>>>> {
>>>>>>    Status status = context.getStatus();
>>>>>>    Map<Status, Filter>    map = fsmMap.get( currentFilter );
>>>>>>    Filter nextFilter = map.get( status );
>>>>>> 
>>>>>>    nextFilter.messageReceived( context );
>>>>>> }
>>>>>> This strikes me as pretty complex, jmho.  Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
>>>>> the alternative would be something like :
>>>>> 
>>>>> void messageReceived( context )
>>>>> {
>>>>>   ... // do something, updating the context, eventually setting a status
>>>>>  fsmMap.get( this ).get( status ).messageReceived( context );
>>>>>   ... // do something after the call
>>>>> }
>>>>> 
>>>>> No controller, but a long list of chained call.
>>>> But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.
>>> If we delegate the transition to the controller, then we can't have post actions... Obviously, not having post actions makes it easier. (Post action are really important if we want to do something when we come back from the application.)
>> I think we're getting to some interesting bits. Can you provide more exact detail?
> 
> One very simple example, taken from the ProfilerFilter :
> 
>    @Override
>    public void messageReceived(NextFilter nextFilter, IoSession session,
>            Object message) throws Exception {
>        if (profileMessageReceived) {
>            long start = timeNow();
>            nextFilter.messageReceived(session, message);
>            long end = timeNow();
>            messageReceivedTimerWorker.addNewDuration(end - start);
>        } else {
>            nextFilter.messageReceived(session, message);
>        }
>    }
> 
> If you depend on the controller to call thenext filter, then you have no easy way to compute the time it takes to process the action, as you won't be able to execute the post action.

This is a good use case, instrumentation of the protocol stack.  Something to think about.

What I still object to is forcing filters to participate via this code bit:

 fsmMap.get( this ).get( status ).messageReceived( context );
> 


> Note that the decoding of multiple messages within one PDU won't be possible either without being able to process post-actions. (see below)
>>> One clear exemple would be a decoder processing a PDU with more than one message : you can't anymore loop on the PDU if you delegate the next call to the controller.
>> What is the format of this PDU and how is it presented to the FSM, i.e. in what kind of pieces does it arrive?
> 
> You get an array of bytes, containing potentially more than one message. The fact is that you have no way to get a byte array from the socket as soon as a complete message has been received : the socket does not know anything about messages.
> 
> You just have to assume that the PDU you've got can be :
> - either a portion of a message, and you have to wait for more bytes in order to produce a message
> - a full message, once decoded
> - more than one message you have to send to the handler one by one
> - some full messages plus a fraction of a message

I had/have the same understanding of how to crack a PDU and pass on translated messages.  This can easily, and I think a fare bit cleaner, be accomplished using the mechanism that I propose as well.

>>>> With that said I think that an FSM where we have, here letters are filters:
>>>> 
>>>> [outside filter] ->   {A ->   [state change decides to send to] ->   B ->    [state change decides to send to]  ->   C} ->   [outside filter]
>>>> 
>>>> is very confusing.  What protocol would require that?  Just an honest question; one does not come to my mind atm.
>>> all of them :) This is what we currently do in MINA.
>> I think that I am hearing a reply that explains that all the protocols are implemented in this way.  I'm not hearing an explanation as to why it *must* be that way.
> 
> simply because you can't move to the next filter unless you have transformed what you've got from the previous filter. If we exclude all the utility filters (like the loggers), a filter can only process a certain type of message, and produce another type of message. The chain of filters is dictated by the transformation done at each step. One good example is LDAP processing : in order to decode a LDAP message, you first have to decode the TLVs, then you can decode the messages themselves. A LDAP chain would be something like :
> 
> [outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP decoder filter -> (LDAPmessages) } -> [outside filter]
> 
> (add to this the fact that you may loop on the TLV filter *and* the LDAP filter, plus the fact that you may have to wait for more bytes)
> 
> Now, it makes *no sense* to exchange the filters. It will simply not work. It's the very same for any protocol we will process with such a mechanism.
> 
> In other words, the order the filters are executed is not random. It's fixed by design, and does not change (as soon as we have ruled out the possibility to have a dynamic chain).
> 
> 
> Another way to see this mechanism is that it's a path from one point to another : you may have many different paths, but for a set of bytes, you will always follow the same path. The only way to follow two different paths is when you get two different sets of bytes.

I'm not sure that this needs to be a single FSM.  Why not

[outside filter] -> (bytes) -> [TLV decoder filter] -> (TLVs) -> [LDAP decoder filter] -> (LDAPmessages) -> [outside filter]

I hear "looping" being a justification but it strikes me that using an FSM obfuscates things needlessly as I believe that a simple filter will do.

Is there some code I can look at to see your above implementation?  I think here is a perfect case for code bits to compare.


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>>>
>>>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>>> What I have in mind is much more something like :
>>>>>
>>>>> void messageReceived( context )
>>>>> {
>>>>>     ... // do something, updating the context, eventually setting a status
>>>>>    controller.callNextFilter( context, currentFilter );
>>>>>     ... // do something after the call
>>>>> }
>>>>>
>>>>> and in controller :
>>>>> void callNextFilter( Context context, Filter currentFilter )
>>>>> {
>>>>>     Status status = context.getStatus();
>>>>>     Map<Status, Filter>    map = fsmMap.get( currentFilter );
>>>>>     Filter nextFilter = map.get( status );
>>>>>
>>>>>     nextFilter.messageReceived( context );
>>>>> }
>>>>> This strikes me as pretty complex, jmho.  Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
>>>> the alternative would be something like :
>>>>
>>>> void messageReceived( context )
>>>> {
>>>>    ... // do something, updating the context, eventually setting a status
>>>>   fsmMap.get( this ).get( status ).messageReceived( context );
>>>>    ... // do something after the call
>>>> }
>>>>
>>>> No controller, but a long list of chained call.
>>> But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.
>> If we delegate the transition to the controller, then we can't have post actions... Obviously, not having post actions makes it easier. (Post action are really important if we want to do something when we come back from the application.)
> I think we're getting to some interesting bits. Can you provide more exact detail?

One very simple example, taken from the ProfilerFilter :

     @Override
     public void messageReceived(NextFilter nextFilter, IoSession session,
             Object message) throws Exception {
         if (profileMessageReceived) {
             long start = timeNow();
             nextFilter.messageReceived(session, message);
             long end = timeNow();
             messageReceivedTimerWorker.addNewDuration(end - start);
         } else {
             nextFilter.messageReceived(session, message);
         }
     }

If you depend on the controller to call thenext filter, then you have no 
easy way to compute the time it takes to process the action, as you 
won't be able to execute the post action.

Note that the decoding of multiple messages within one PDU won't be 
possible either without being able to process post-actions. (see below)
>> One clear exemple would be a decoder processing a PDU with more than one message : you can't anymore loop on the PDU if you delegate the next call to the controller.
> What is the format of this PDU and how is it presented to the FSM, i.e. in what kind of pieces does it arrive?

You get an array of bytes, containing potentially more than one message. 
The fact is that you have no way to get a byte array from the socket as 
soon as a complete message has been received : the socket does not know 
anything about messages.

You just have to assume that the PDU you've got can be :
- either a portion of a message, and you have to wait for more bytes in 
order to produce a message
- a full message, once decoded
- more than one message you have to send to the handler one by one
- some full messages plus a fraction of a message
>
>>> With that said I think that an FSM where we have, here letters are filters:
>>>
>>> [outside filter] ->   {A ->   [state change decides to send to] ->   B ->    [state change decides to send to]  ->   C} ->   [outside filter]
>>>
>>> is very confusing.  What protocol would require that?  Just an honest question; one does not come to my mind atm.
>> all of them :) This is what we currently do in MINA.
> I think that I am hearing a reply that explains that all the protocols are implemented in this way.  I'm not hearing an explanation as to why it *must* be that way.

simply because you can't move to the next filter unless you have 
transformed what you've got from the previous filter. If we exclude all 
the utility filters (like the loggers), a filter can only process a 
certain type of message, and produce another type of message. The chain 
of filters is dictated by the transformation done at each step. One good 
example is LDAP processing : in order to decode a LDAP message, you 
first have to decode the TLVs, then you can decode the messages 
themselves. A LDAP chain would be something like :

[outside filter] -> (bytes) -> { TLV decoder filter -> (TLVs) -> LDAP 
decoder filter -> (LDAPmessages) } -> [outside filter]

(add to this the fact that you may loop on the TLV filter *and* the LDAP 
filter, plus the fact that you may have to wait for more bytes)

Now, it makes *no sense* to exchange the filters. It will simply not 
work. It's the very same for any protocol we will process with such a 
mechanism.

In other words, the order the filters are executed is not random. It's 
fixed by design, and does not change (as soon as we have ruled out the 
possibility to have a dynamic chain).


Another way to see this mechanism is that it's a path from one point to 
another : you may have many different paths, but for a set of bytes, you 
will always follow the same path. The only way to follow two different 
paths is when you get two different sets of bytes.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:

> On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>> 
>>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>>> What I have in mind is much more something like :
>>>> 
>>>> void messageReceived( context )
>>>> {
>>>>    ... // do something, updating the context, eventually setting a status
>>>>   controller.callNextFilter( context, currentFilter );
>>>>    ... // do something after the call
>>>> }
>>>> 
>>>> and in controller :
>>>> void callNextFilter( Context context, Filter currentFilter )
>>>> {
>>>>    Status status = context.getStatus();
>>>>    Map<Status, Filter>   map = fsmMap.get( currentFilter );
>>>>    Filter nextFilter = map.get( status );
>>>> 
>>>>    nextFilter.messageReceived( context );
>>>> }
>>>> This strikes me as pretty complex, jmho.  Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
>>> the alternative would be something like :
>>> 
>>> void messageReceived( context )
>>> {
>>>   ... // do something, updating the context, eventually setting a status
>>>  fsmMap.get( this ).get( status ).messageReceived( context );
>>>   ... // do something after the call
>>> }
>>> 
>>> No controller, but a long list of chained call.
>> But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.
> 
> If we delegate the transition to the controller, then we can't have post actions... Obviously, not having post actions makes it easier. (Post action are really important if we want to do something when we come back from the application.)

I think we're getting to some interesting bits. Can you provide more exact detail?
> 
> One clear exemple would be a decoder processing a PDU with more than one message : you can't anymore loop on the PDU if you delegate the next call to the controller.

What is the format of this PDU and how is it presented to the FSM, i.e. in what kind of pieces does it arrive?

>> With that said I think that an FSM where we have, here letters are filters:
>> 
>> [outside filter] ->  {A ->  [state change decides to send to] ->  B ->   [state change decides to send to]  ->  C} ->  [outside filter]
>> 
>> is very confusing.  What protocol would require that?  Just an honest question; one does not come to my mind atm.
> 
> all of them :) This is what we currently do in MINA.

I think that I am hearing a reply that explains that all the protocols are implemented in this way.  I'm not hearing an explanation as to why it *must* be that way.


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>>> What I have in mind is much more something like :
>>>
>>> void messageReceived( context )
>>> {
>>>     ... // do something, updating the context, eventually setting a status
>>>    controller.callNextFilter( context, currentFilter );
>>>     ... // do something after the call
>>> }
>>>
>>> and in controller :
>>> void callNextFilter( Context context, Filter currentFilter )
>>> {
>>>     Status status = context.getStatus();
>>>     Map<Status, Filter>   map = fsmMap.get( currentFilter );
>>>     Filter nextFilter = map.get( status );
>>>
>>>     nextFilter.messageReceived( context );
>>> }
>>> This strikes me as pretty complex, jmho.  Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
>> the alternative would be something like :
>>
>> void messageReceived( context )
>> {
>>    ... // do something, updating the context, eventually setting a status
>>   fsmMap.get( this ).get( status ).messageReceived( context );
>>    ... // do something after the call
>> }
>>
>> No controller, but a long list of chained call.
> But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.

If we delegate the transition to the controller, then we can't have post 
actions... Obviously, not having post actions makes it easier. (Post 
action are really important if we want to do something when we come back 
from the application.)

One clear exemple would be a decoder processing a PDU with more than one 
message : you can't anymore loop on the PDU if you delegate the next 
call to the controller.

>
>
> With that said I think that an FSM where we have, here letters are filters:
>
> [outside filter] ->  {A ->  [state change decides to send to] ->  B ->   [state change decides to send to]  ->  C} ->  [outside filter]
>
> is very confusing.  What protocol would require that?  Just an honest question; one does not come to my mind atm.

all of them :) This is what we currently do in MINA.

>
>> Also the fsmMap must be known by the current filter.
>>> Look at my implementation of org.apache.mina.link.DownState as an example.  This framework does not require a call to a controller for the whole thing to work.  This filter merely focuses on its task at hand and implementation does not leak as much into its message received method.
>> Ok, I'll give it a look.
>>>> The controller will decide which filter must be called depending on the context status.
>>>>
>>>> (Note that the controller should also decide which message to call, for instance, it can decide that it has to call a messageReceived() because it's caller was processing a messageReceived())
>>> I feel that, for the most part, we all have been doing a lot of discussions without any mock implementations of real protocols to help us gauge our API decisions.
>> I'm "lucky" enough to have played with MINA for more than 5 years, facing many differents kind of protocol based on it, plus having answered many of MINA user's questions regarding how to implement many different kind of protocol.
>>
>> Trust me on that, when I'm thinking about the new API, I always have in mind the different "real world" protocols we have to deal with. That includes :
>> - obviously LDAP protocol, which is a binary, two layer codec, demuxed protocol
>> - NTP based on UDP
>> - Kerberos based on UDP *and* TCP
>> - HTTP, ie newline terminated decoder, a cumulative decoder
>> - a few proprietary protocole implemented using MINA, with fixed size data, or LV type PDUs
> I think you missed my point.  I am not questioning anyone's expertise in the industry.  I am calling out the current modus operandi of the current API design process and it's need for real world mockups.

Ok, understood. You are reverting the process : we define the protocols, 
then we try to implement them with different way to manage filters.
>
>>>   I'd like to see lots of little sandbox branches where people show what protocol implementations would end up looking like for the feature they are proposing.  It's a fantastic way to gauge API design differences.
>> I like Julien's approach : designing a working solution, not covering all our bases right now, and implement a few existing protocols. Then moving forward.
> I'm sorry but that seems totally backwards to me.  The API design should be the framework from which the working solution evolves.  Starting with the implementations could automatically close the doors on useful API features.
Unless we ditch those implementations. But I understand your point. 
However, even if we define some protocols, we will need some 
implementation to test them.



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:

> On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
>> What I have in mind is much more something like :
>> 
>> void messageReceived( context )
>> {
>>    ... // do something, updating the context, eventually setting a status
>>   controller.callNextFilter( context, currentFilter );
>>    ... // do something after the call
>> }
>> 
>> and in controller :
>> void callNextFilter( Context context, Filter currentFilter )
>> {
>>    Status status = context.getStatus();
>>    Map<Status, Filter>  map = fsmMap.get( currentFilter );
>>    Filter nextFilter = map.get( status );
>> 
>>    nextFilter.messageReceived( context );
>> }
>> This strikes me as pretty complex, jmho.  Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
> the alternative would be something like :
> 
> void messageReceived( context )
> {
>   ... // do something, updating the context, eventually setting a status
>  fsmMap.get( this ).get( status ).messageReceived( context );
>   ... // do something after the call
> }
> 
> No controller, but a long list of chained call.

But we're still forcing the filter to participate in things that really should be the domain of the controller not the filter.  

With that said I think that an FSM where we have, here letters are filters:

[outside filter] -> {A -> [state change decides to send to] -> B ->  [state change decides to send to]  -> C} -> [outside filter]

is very confusing.  What protocol would require that?  Just an honest question; one does not come to my mind atm.

> Also the fsmMap must be known by the current filter.
>> Look at my implementation of org.apache.mina.link.DownState as an example.  This framework does not require a call to a controller for the whole thing to work.  This filter merely focuses on its task at hand and implementation does not leak as much into its message received method.
> 
> Ok, I'll give it a look.
>> 
>>> The controller will decide which filter must be called depending on the context status.
>>> 
>>> (Note that the controller should also decide which message to call, for instance, it can decide that it has to call a messageReceived() because it's caller was processing a messageReceived())
>> I feel that, for the most part, we all have been doing a lot of discussions without any mock implementations of real protocols to help us gauge our API decisions.
> I'm "lucky" enough to have played with MINA for more than 5 years, facing many differents kind of protocol based on it, plus having answered many of MINA user's questions regarding how to implement many different kind of protocol.
> 
> Trust me on that, when I'm thinking about the new API, I always have in mind the different "real world" protocols we have to deal with. That includes :
> - obviously LDAP protocol, which is a binary, two layer codec, demuxed protocol
> - NTP based on UDP
> - Kerberos based on UDP *and* TCP
> - HTTP, ie newline terminated decoder, a cumulative decoder
> - a few proprietary protocole implemented using MINA, with fixed size data, or LV type PDUs

I think you missed my point.  I am not questioning anyone's expertise in the industry.  I am calling out the current modus operandi of the current API design process and it's need for real world mockups.

>> Our tendency is to dive into the implementation details and then shoehorn protocols into the resultant API.
> Not exactly my state of mind... I'm more trying to find the best possible solution, dealing with many constraints :
> - ease of use
> - coverage of the different use cases
> - memory consumption
> - ease of debuging
> - speed

Definitely good points.  We all want this but they speak nothing to the process of coming up with an API.  My point is to have concrete examples of how the API bits we are proposing would look.  A perfect example is your and my ideas of how the FSM should work.  With no concrete mocked up bits to see how the two APIs would influence the implementation of a protocol the discussion devolves into arguments over aesthetic opinions.

>>  This is why Mina 2 is so bloated and daunting.
> MINA 2 is bloated for different reasons, and I think I have already discussed some of them.
> 
> One of the most problematic reason is that MINA 2 (and 1) was a one man show. This is why I'm really pleased to have those discussion here, even if it seems to be a bike-shedding discussion. It is not.

Agreed on the last bit.  Anyone who thinks the current discussions about the API design are bike shed issues never designed an API. 

>>  I'd like to see lots of little sandbox branches where people show what protocol implementations would end up looking like for the feature they are proposing.  It's a fantastic way to gauge API design differences.
> I like Julien's approach : designing a working solution, not covering all our bases right now, and implement a few existing protocols. Then moving forward.

I'm sorry but that seems totally backwards to me.  The API design should be the framework from which the working solution evolves.  Starting with the implementations could automatically close the doors on useful API features.


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
> What I have in mind is much more something like :
>
> void messageReceived( context )
> {
>     ... // do something, updating the context, eventually setting a status
>    controller.callNextFilter( context, currentFilter );
>     ... // do something after the call
> }
>
> and in controller :
> void callNextFilter( Context context, Filter currentFilter )
> {
>     Status status = context.getStatus();
>     Map<Status, Filter>  map = fsmMap.get( currentFilter );
>     Filter nextFilter = map.get( status );
>
>     nextFilter.messageReceived( context );
> }
> This strikes me as pretty complex, jmho.  Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.
the alternative would be something like :

void messageReceived( context )
{
    ... // do something, updating the context, eventually setting a status
   fsmMap.get( this ).get( status ).messageReceived( context );
    ... // do something after the call
}

No controller, but a long list of chained call.

Also the fsmMap must be known by the current filter.
> Look at my implementation of org.apache.mina.link.DownState as an example.  This framework does not require a call to a controller for the whole thing to work.  This filter merely focuses on its task at hand and implementation does not leak as much into its message received method.

Ok, I'll give it a look.
>
>> The controller will decide which filter must be called depending on the context status.
>>
>> (Note that the controller should also decide which message to call, for instance, it can decide that it has to call a messageReceived() because it's caller was processing a messageReceived())
> I feel that, for the most part, we all have been doing a lot of discussions without any mock implementations of real protocols to help us gauge our API decisions.
I'm "lucky" enough to have played with MINA for more than 5 years, 
facing many differents kind of protocol based on it, plus having 
answered many of MINA user's questions regarding how to implement many 
different kind of protocol.

Trust me on that, when I'm thinking about the new API, I always have in 
mind the different "real world" protocols we have to deal with. That 
includes :
- obviously LDAP protocol, which is a binary, two layer codec, demuxed 
protocol
- NTP based on UDP
- Kerberos based on UDP *and* TCP
- HTTP, ie newline terminated decoder, a cumulative decoder
- a few proprietary protocole implemented using MINA, with fixed size 
data, or LV type PDUs


> Our tendency is to dive into the implementation details and then shoehorn protocols into the resultant API.
Not exactly my state of mind... I'm more trying to find the best 
possible solution, dealing with many constraints :
- ease of use
- coverage of the different use cases
- memory consumption
- ease of debuging
- speed

>   This is why Mina 2 is so bloated and daunting.
MINA 2 is bloated for different reasons, and I think I have already 
discussed some of them.

One of the most problematic reason is that MINA 2 (and 1) was a one man 
show. This is why I'm really pleased to have those discussion here, even 
if it seems to be a bike-shedding discussion. It is not.

>   I'd like to see lots of little sandbox branches where people show what protocol implementations would end up looking like for the feature they are proposing.  It's a fantastic way to gauge API design differences.
I like Julien's approach : designing a working solution, not covering 
all our bases right now, and implement a few existing protocols. Then 
moving forward.



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:

> On 8/26/11 6:16 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
>> 
>>> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>>> 
>>>> 
>>>> <theory>
>>>> In a FSM, you transit from Si to Sj, following a transition Ta, which depends on a context. You may also transit to a state Sk, following a different transition Tb, if the context is different.
>>>> 
>>>> Selection the transition to follow is all about knowing what's the context is, and in my sample, this was what I call the 'state', which was most certainly an error, as it's clearly a transition. I should have wrote :
>>>> 
>>>> F --(transition1)-->    G
>>>> or
>>>> F --(transition2)-->    H
>>>> 
>>>> where F, G, H are filters (ore "states")
>>>> 
>>>> are we on the same page ?
>>>> 
>>>> </theory>
>>>> Not at all.  :)
>>>> 
>>>> Are F, G, H filters inside the FSM or are they external to the FSM?
>>> They are filters in the FSM.
>> Ok, now I know where you're coming from.  For me I have a map of chains
>> 
>> Map<State, Chain>  states = …
>> State current;
> 
> What is Chain in this context ?

Chain is a simple filter or graph of filters that can declare what the next state of the FSM should be.

> I don't think it's enough to build the demux. We probably would need something like :
> 
> Map<Status, Filter> filterMap = ...
> Map<Filter, Map<Status, Filter>> fsmMap = ...
> 
> ( I keep Filter, but a Filter for us is a State in a FSM)
> 
> otherwise, the controller can't select the next Filter without having a clue about the context

Ahh, cool, more clarity.  I never intended FSMs to replace a demux.  

>> void send(T message)
>> {
>>     Chain chain = states.get(current);
>>    current = chain.send(message);
>> }
> 
> What I have in mind is much more something like :
> 
> void messageReceived( context )
> {
>    ... // do something, updating the context, eventually setting a status
>   controller.callNextFilter( context, currentFilter );
>    ... // do something after the call
> }
> 
> and in controller :
> void callNextFilter( Context context, Filter currentFilter )
> {
>    Status status = context.getStatus();
>    Map<Status, Filter> map = fsmMap.get( currentFilter );
>    Filter nextFilter = map.get( status );
> 
>    nextFilter.messageReceived( context );
> }

This strikes me as pretty complex, jmho.  Also, I don't like the idea of forcing the filter to call the controller.callNextFilter() to make things work.  Look at my implementation of org.apache.mina.link.DownState as an example.  This framework does not require a call to a controller for the whole thing to work.  This filter merely focuses on its task at hand and implementation does not leak as much into its message received method.

> The controller will decide which filter must be called depending on the context status.
> 
> (Note that the controller should also decide which message to call, for instance, it can decide that it has to call a messageReceived() because it's caller was processing a messageReceived())

I feel that, for the most part, we all have been doing a lot of discussions without any mock implementations of real protocols to help us gauge our API decisions.  Our tendency is to dive into the implementation details and then shoehorn protocols into the resultant API.  This is why Mina 2 is so bloated and daunting.  I'd like to see lots of little sandbox branches where people show what protocol implementations would end up looking like for the feature they are proposing.  It's a fantastic way to gauge API design differences.

To that end I invite everyone to flesh out, as I am doing in my sandbox branch, the following protocols:

Link state protocol - implementation of [1]
Group protocol - [2]
Paxos - ideally would use the above protocols
SSL
Checksum
MUX/DEMUX

[1] http://caltechparadise.library.caltech.edu/32/
[2] http://authors.library.caltech.edu/5410/


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 6:16 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>>
>>>
>>> <theory>
>>> In a FSM, you transit from Si to Sj, following a transition Ta, which depends on a context. You may also transit to a state Sk, following a different transition Tb, if the context is different.
>>>
>>> Selection the transition to follow is all about knowing what's the context is, and in my sample, this was what I call the 'state', which was most certainly an error, as it's clearly a transition. I should have wrote :
>>>
>>> F --(transition1)-->    G
>>> or
>>> F --(transition2)-->    H
>>>
>>> where F, G, H are filters (ore "states")
>>>
>>> are we on the same page ?
>>>
>>> </theory>
>>> Not at all.  :)
>>>
>>> Are F, G, H filters inside the FSM or are they external to the FSM?
>> They are filters in the FSM.
> Ok, now I know where you're coming from.  For me I have a map of chains
>
> Map<State, Chain>  states = …
> State current;

What is Chain in this context ?

I don't think it's enough to build the demux. We probably would need 
something like :

Map<Status, Filter> filterMap = ...
Map<Filter, Map<Status, Filter>> fsmMap = ...

( I keep Filter, but a Filter for us is a State in a FSM)

otherwise, the controller can't select the next Filter without having a 
clue about the context
>
> void send(T message)
> {
>      Chain chain = states.get(current);
>     current = chain.send(message);
> }

What I have in mind is much more something like :

void messageReceived( context )
{
     ... // do something, updating the context, eventually setting a status
    controller.callNextFilter( context, currentFilter );
     ... // do something after the call
}

and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
     Status status = context.getStatus();
     Map<Status, Filter> map = fsmMap.get( currentFilter );
     Filter nextFilter = map.get( status );

     nextFilter.messageReceived( context );
}

The controller will decide which filter must be called depending on the 
context status.

(Note that the controller should also decide which message to call, for 
instance, it can decide that it has to call a messageReceived() because 
it's caller was processing a messageReceived())


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:

> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>> 
>>> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>>>> 
>>>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>>>> 
>>>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>    wrote:
>>>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>>>> 
>>>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>>>>>  wrote:
>>>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>>>> 
>>>>>>>>>>>> // create the fitler chain for this service
>>>>>>>>>>>> List<IoFilter>     filters = new ArrayList<IoFilter>();
>>>>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>>>> 
>>>>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>>>> 
>>>>>>>>>>>> acceptor.bind(...);
>>>>>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>>>>>> 
>>>>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>>>>> 
>>>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>>>> 
>>>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>>>> 
>>>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>>>> 
>>>>>>>>>> About the code in the sandbox :
>>>>>>>>>> 
>>>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>>>>>> right place ?
>>>>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>>>> 
>>>>>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>>>>>> you have a concrete use case in mind for that ?
>>>>>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>>>>>> would all of this fit into the grand scheme of things?
>>>>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>>>> 
>>>>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>>>>> : http://s.apache.org/A9W
>>>>>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>>>>> I do agree. The proposed solution on http://s.apache.org/A9W is what we currently have, and it's tedious to manage.
>>>>> 
>>>>> It would be way better to be able to let the controler call the next filter based on an evaluation method based on the current state.
>>>>> 
>>>>> 
>>>>> Now, the question is : how do the controller knows which filter to call next ? It must have the current state, and it must be able to make the connection.
>>>>> 
>>>>> For instance, let's say that from filter F we can switch to either filter G or filter H, depending on the state we transit to in F.
>>>>> 
>>>>> F --(state1)-->   G
>>>>> or
>>>>> F --(state2)-->   H
>>>>> 
>>>>> That means the controller has a map { (F, state1, G), (F, state2, H)} somewhere. State should be passed to the controller too :
>>>>> 
>>>>> ...
>>>>> controller.nextFilter( newState );
>>>>> ...
>>>>> 
>>>>> Pretty theorical at this point... I'm sorry not to have a lot of time to code this, I do realize that for you guys implementing ideas it's a PITA...
>>>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>>>> 
>>>> ->   [FSM1] ->   [Filter] ->   [FSM2] ->   [Filter]
>>>> 
>>>> Inside the FSM there could be chains, but there would be one chain per state.
>>> Not sure I grok what you say here. There is more than one state, and from each state, you may have more than one transition.
>>> 
>>> Maybe it's just a problem of vocabulary...
>>> 
>>> <theory>
>>> In a FSM, you transit from Si to Sj, following a transition Ta, which depends on a context. You may also transit to a state Sk, following a different transition Tb, if the context is different.
>>> 
>>> Selection the transition to follow is all about knowing what's the context is, and in my sample, this was what I call the 'state', which was most certainly an error, as it's clearly a transition. I should have wrote :
>>> 
>>> F --(transition1)-->   G
>>> or
>>> F --(transition2)-->   H
>>> 
>>> where F, G, H are filters (ore "states")
>>> 
>>> are we on the same page ?
>>> 
>>> </theory>
>> Not at all.  :)
>> 
>> Are F, G, H filters inside the FSM or are they external to the FSM?
> 
> They are filters in the FSM.

Ok, now I know where you're coming from.  For me I have a map of chains

Map<State, Chain> states = …
State current;

void send(T message)
{
    Chain chain = states.get(current);
   current = chain.send(message);
}

So the effect is

[outside filter] -> [FSM  [current chain] ] -> [outside filter]

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 9:15 AM, Julien Vermillard wrote:

> On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>> 
>>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>> 
>>>> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>>>>> 
>>>>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>>>>> 
>>>>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>>>>> 
>>>>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>>>>> 
>>>>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel
>>>>>>>> Lecharny<el...@gmail.com>    wrote:
>>>>>>>>> 
>>>>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>>>>> 
>>>>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>>>>> 
>>>>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D.
>>>>>>>>>>> Cabrera<li...@toolazydogs.com>
>>>>>>>>>>>  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed
>>>>>>>>>>>>> to
>>>>>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>>>>> 
>>>>>>>>>>>>> // create the fitler chain for this service
>>>>>>>>>>>>> List<IoFilter>     filters = new ArrayList<IoFilter>();
>>>>>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>>>>> 
>>>>>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>>>>> 
>>>>>>>>>>>>> acceptor.bind(...);
>>>>>>>>>>>> 
>>>>>>>>>>>> How do we make chains where two filters feed into one or one
>>>>>>>>>>>> filter
>>>>>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate
>>>>>>>>>>>> this via:
>>>>>>>>>>>> 
>>>>>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be
>>>>>>>>>>>> written
>>>>>>>>>>>> 
>>>>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>>>>> 
>>>>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>>>>> 
>>>>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>>>>> 
>>>>>>>>>>> About the code in the sandbox :
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at
>>>>>>>>>>> the
>>>>>>>>>>> right place ?
>>>>>>>>>> 
>>>>>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>>>>> 
>>>>>>>>>>> About the "filters feed into one or one filter feeds two filters",
>>>>>>>>>>> do
>>>>>>>>>>> you have a concrete use case in mind for that ?
>>>>>>>>>> 
>>>>>>>>>> The above example does, Foo and the link state filter.  I'm sure
>>>>>>>>>> that
>>>>>>>>>> we've discussed this before.  Another example is a mux/demux
>>>>>>>>>> situation.  How
>>>>>>>>>> would all of this fit into the grand scheme of things?
>>>>>>>>> 
>>>>>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>>>>> 
>>>>>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>>>>>> : http://s.apache.org/A9W
>>>>>>> 
>>>>>>> I think we need to make graphing a 1st class citizen and not buried
>>>>>>> inside another filter class.
>>>>>> 
>>>>>> I do agree. The proposed solution on http://s.apache.org/A9W is what we
>>>>>> currently have, and it's tedious to manage.
>>>>>> 
>>>>>> It would be way better to be able to let the controler call the next
>>>>>> filter based on an evaluation method based on the current state.
>>>>>> 
>>>>>> 
>>>>>> Now, the question is : how do the controller knows which filter to call
>>>>>> next ? It must have the current state, and it must be able to make the
>>>>>> connection.
>>>>>> 
>>>>>> For instance, let's say that from filter F we can switch to either
>>>>>> filter G or filter H, depending on the state we transit to in F.
>>>>>> 
>>>>>> F --(state1)-->   G
>>>>>> or
>>>>>> F --(state2)-->   H
>>>>>> 
>>>>>> That means the controller has a map { (F, state1, G), (F, state2, H)}
>>>>>> somewhere. State should be passed to the controller too :
>>>>>> 
>>>>>> ...
>>>>>> controller.nextFilter( newState );
>>>>>> ...
>>>>>> 
>>>>>> Pretty theorical at this point... I'm sorry not to have a lot of time
>>>>>> to code this, I do realize that for you guys implementing ideas it's a
>>>>>> PITA...
>>>>> 
>>>>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>>>>> 
>>>>> ->   [FSM1] ->   [Filter] ->   [FSM2] ->   [Filter]
>>>>> 
>>>>> Inside the FSM there could be chains, but there would be one chain per
>>>>> state.
>>>> 
>>>> Not sure I grok what you say here. There is more than one state, and from
>>>> each state, you may have more than one transition.
>>>> 
>>>> Maybe it's just a problem of vocabulary...
>>>> 
>>>> <theory>
>>>> In a FSM, you transit from Si to Sj, following a transition Ta, which
>>>> depends on a context. You may also transit to a state Sk, following a
>>>> different transition Tb, if the context is different.
>>>> 
>>>> Selection the transition to follow is all about knowing what's the
>>>> context is, and in my sample, this was what I call the 'state', which was
>>>> most certainly an error, as it's clearly a transition. I should have wrote :
>>>> 
>>>> F --(transition1)-->   G
>>>> or
>>>> F --(transition2)-->   H
>>>> 
>>>> where F, G, H are filters (ore "states")
>>>> 
>>>> are we on the same page ?
>>>> 
>>>> </theory>
>>> 
>>> Not at all.  :)
>>> 
>>> Are F, G, H filters inside the FSM or are they external to the FSM?
>> 
>> They are filters in the FSM.
>> 
> 
> Until your minds are clear about where to go about muxing,FSM and
> filters I'll continue low-level implementation of MINA 3.0. The actual
> filter chain is enough for me to do protocol implementation and perf
> testing the NIO loops.

If you think it's useful to work out lower level details while the API design is still happening, cool.  It may happen that decisions about the API will affect your work.  With that said, I think that it would be interesting to see what can be done for an NIO loop that is different from the existing Mina ones. 


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 6:15 PM, Julien Vermillard wrote:
> On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny<el...@gmail.com>  wrote:
>> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>>
>>>> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>>>>>
>>>>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>>>>>
>>>>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel
>>>>>>>> Lecharny<el...@gmail.com>      wrote:
>>>>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>>>>>
>>>>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D.
>>>>>>>>>>> Cabrera<li...@toolazydogs.com>
>>>>>>>>>>>   wrote:
>>>>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed
>>>>>>>>>>>>> to
>>>>>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>>>>>
>>>>>>>>>>>>> // create the fitler chain for this service
>>>>>>>>>>>>> List<IoFilter>       filters = new ArrayList<IoFilter>();
>>>>>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>>>>>
>>>>>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>>>>>
>>>>>>>>>>>>> acceptor.bind(...);
>>>>>>>>>>>> How do we make chains where two filters feed into one or one
>>>>>>>>>>>> filter
>>>>>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate
>>>>>>>>>>>> this via:
>>>>>>>>>>>>
>>>>>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be
>>>>>>>>>>>> written
>>>>>>>>>>>>
>>>>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>>>>>
>>>>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>>>>>
>>>>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>>>>>
>>>>>>>>>>> About the code in the sandbox :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at
>>>>>>>>>>> the
>>>>>>>>>>> right place ?
>>>>>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>>>>>
>>>>>>>>>>> About the "filters feed into one or one filter feeds two filters",
>>>>>>>>>>> do
>>>>>>>>>>> you have a concrete use case in mind for that ?
>>>>>>>>>> The above example does, Foo and the link state filter.  I'm sure
>>>>>>>>>> that
>>>>>>>>>> we've discussed this before.  Another example is a mux/demux
>>>>>>>>>> situation.  How
>>>>>>>>>> would all of this fit into the grand scheme of things?
>>>>>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>>>>>
>>>>>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>>>>>> : http://s.apache.org/A9W
>>>>>>> I think we need to make graphing a 1st class citizen and not buried
>>>>>>> inside another filter class.
>>>>>> I do agree. The proposed solution on http://s.apache.org/A9W is what we
>>>>>> currently have, and it's tedious to manage.
>>>>>>
>>>>>> It would be way better to be able to let the controler call the next
>>>>>> filter based on an evaluation method based on the current state.
>>>>>>
>>>>>>
>>>>>> Now, the question is : how do the controller knows which filter to call
>>>>>> next ? It must have the current state, and it must be able to make the
>>>>>> connection.
>>>>>>
>>>>>> For instance, let's say that from filter F we can switch to either
>>>>>> filter G or filter H, depending on the state we transit to in F.
>>>>>>
>>>>>> F --(state1)-->     G
>>>>>> or
>>>>>> F --(state2)-->     H
>>>>>>
>>>>>> That means the controller has a map { (F, state1, G), (F, state2, H)}
>>>>>> somewhere. State should be passed to the controller too :
>>>>>>
>>>>>> ...
>>>>>> controller.nextFilter( newState );
>>>>>> ...
>>>>>>
>>>>>> Pretty theorical at this point... I'm sorry not to have a lot of time
>>>>>> to code this, I do realize that for you guys implementing ideas it's a
>>>>>> PITA...
>>>>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>>>>>
>>>>> ->     [FSM1] ->     [Filter] ->     [FSM2] ->     [Filter]
>>>>>
>>>>> Inside the FSM there could be chains, but there would be one chain per
>>>>> state.
>>>> Not sure I grok what you say here. There is more than one state, and from
>>>> each state, you may have more than one transition.
>>>>
>>>> Maybe it's just a problem of vocabulary...
>>>>
>>>> <theory>
>>>> In a FSM, you transit from Si to Sj, following a transition Ta, which
>>>> depends on a context. You may also transit to a state Sk, following a
>>>> different transition Tb, if the context is different.
>>>>
>>>> Selection the transition to follow is all about knowing what's the
>>>> context is, and in my sample, this was what I call the 'state', which was
>>>> most certainly an error, as it's clearly a transition. I should have wrote :
>>>>
>>>> F --(transition1)-->     G
>>>> or
>>>> F --(transition2)-->     H
>>>>
>>>> where F, G, H are filters (ore "states")
>>>>
>>>> are we on the same page ?
>>>>
>>>> </theory>
>>> Not at all.  :)
>>>
>>> Are F, G, H filters inside the FSM or are they external to the FSM?
>> They are filters in the FSM.
>>
> Until your minds are clear about where to go about muxing,FSM and
> filters I'll continue low-level implementation of MINA 3.0. The actual
> filter chain is enough for me to do protocol implementation and perf
> testing the NIO loops.

Go ahead. The fact that we are brain-storming about some additional 
feature should not stop you to build some good base we can butcher later :)


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
>>
>> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>>
>>> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>>>>
>>>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>>>>
>>>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>>>>
>>>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>>>>
>>>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel
>>>>>>> Lecharny<el...@gmail.com>    wrote:
>>>>>>>>
>>>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>>>>
>>>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D.
>>>>>>>>>> Cabrera<li...@toolazydogs.com>
>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed
>>>>>>>>>>>> to
>>>>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>>>>
>>>>>>>>>>>> // create the fitler chain for this service
>>>>>>>>>>>> List<IoFilter>     filters = new ArrayList<IoFilter>();
>>>>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>>>>
>>>>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>>>>
>>>>>>>>>>>> acceptor.bind(...);
>>>>>>>>>>>
>>>>>>>>>>> How do we make chains where two filters feed into one or one
>>>>>>>>>>> filter
>>>>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate
>>>>>>>>>>> this via:
>>>>>>>>>>>
>>>>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be
>>>>>>>>>>> written
>>>>>>>>>>>
>>>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>>>>
>>>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>>>>
>>>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>>>>
>>>>>>>>>> About the code in the sandbox :
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at
>>>>>>>>>> the
>>>>>>>>>> right place ?
>>>>>>>>>
>>>>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>>>>
>>>>>>>>>> About the "filters feed into one or one filter feeds two filters",
>>>>>>>>>> do
>>>>>>>>>> you have a concrete use case in mind for that ?
>>>>>>>>>
>>>>>>>>> The above example does, Foo and the link state filter.  I'm sure
>>>>>>>>> that
>>>>>>>>> we've discussed this before.  Another example is a mux/demux
>>>>>>>>> situation.  How
>>>>>>>>> would all of this fit into the grand scheme of things?
>>>>>>>>
>>>>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>>>>
>>>>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>>>>> : http://s.apache.org/A9W
>>>>>>
>>>>>> I think we need to make graphing a 1st class citizen and not buried
>>>>>> inside another filter class.
>>>>>
>>>>> I do agree. The proposed solution on http://s.apache.org/A9W is what we
>>>>> currently have, and it's tedious to manage.
>>>>>
>>>>> It would be way better to be able to let the controler call the next
>>>>> filter based on an evaluation method based on the current state.
>>>>>
>>>>>
>>>>> Now, the question is : how do the controller knows which filter to call
>>>>> next ? It must have the current state, and it must be able to make the
>>>>> connection.
>>>>>
>>>>> For instance, let's say that from filter F we can switch to either
>>>>> filter G or filter H, depending on the state we transit to in F.
>>>>>
>>>>> F --(state1)-->   G
>>>>> or
>>>>> F --(state2)-->   H
>>>>>
>>>>> That means the controller has a map { (F, state1, G), (F, state2, H)}
>>>>> somewhere. State should be passed to the controller too :
>>>>>
>>>>> ...
>>>>> controller.nextFilter( newState );
>>>>> ...
>>>>>
>>>>> Pretty theorical at this point... I'm sorry not to have a lot of time
>>>>> to code this, I do realize that for you guys implementing ideas it's a
>>>>> PITA...
>>>>
>>>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>>>>
>>>> ->   [FSM1] ->   [Filter] ->   [FSM2] ->   [Filter]
>>>>
>>>> Inside the FSM there could be chains, but there would be one chain per
>>>> state.
>>>
>>> Not sure I grok what you say here. There is more than one state, and from
>>> each state, you may have more than one transition.
>>>
>>> Maybe it's just a problem of vocabulary...
>>>
>>> <theory>
>>> In a FSM, you transit from Si to Sj, following a transition Ta, which
>>> depends on a context. You may also transit to a state Sk, following a
>>> different transition Tb, if the context is different.
>>>
>>> Selection the transition to follow is all about knowing what's the
>>> context is, and in my sample, this was what I call the 'state', which was
>>> most certainly an error, as it's clearly a transition. I should have wrote :
>>>
>>> F --(transition1)-->   G
>>> or
>>> F --(transition2)-->   H
>>>
>>> where F, G, H are filters (ore "states")
>>>
>>> are we on the same page ?
>>>
>>> </theory>
>>
>> Not at all.  :)
>>
>> Are F, G, H filters inside the FSM or are they external to the FSM?
>
> They are filters in the FSM.
>

Until your minds are clear about where to go about muxing,FSM and
filters I'll continue low-level implementation of MINA 3.0. The actual
filter chain is enough for me to do protocol implementation and perf
testing the NIO loops.

Julien

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>>>
>>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>>>
>>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>    wrote:
>>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>>>
>>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>>>>   wrote:
>>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>>>
>>>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>>>
>>>>>>>>>>> // create the fitler chain for this service
>>>>>>>>>>> List<IoFilter>     filters = new ArrayList<IoFilter>();
>>>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>>>
>>>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>>>
>>>>>>>>>>> acceptor.bind(...);
>>>>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>>>>>
>>>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>>>>
>>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>>>
>>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>>>
>>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>>>
>>>>>>>>> About the code in the sandbox :
>>>>>>>>>
>>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>>>>> right place ?
>>>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>>>
>>>>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>>>>> you have a concrete use case in mind for that ?
>>>>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>>>>> would all of this fit into the grand scheme of things?
>>>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>>>
>>>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>>>> : http://s.apache.org/A9W
>>>>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>>>> I do agree. The proposed solution on http://s.apache.org/A9W is what we currently have, and it's tedious to manage.
>>>>
>>>> It would be way better to be able to let the controler call the next filter based on an evaluation method based on the current state.
>>>>
>>>>
>>>> Now, the question is : how do the controller knows which filter to call next ? It must have the current state, and it must be able to make the connection.
>>>>
>>>> For instance, let's say that from filter F we can switch to either filter G or filter H, depending on the state we transit to in F.
>>>>
>>>> F --(state1)-->   G
>>>> or
>>>> F --(state2)-->   H
>>>>
>>>> That means the controller has a map { (F, state1, G), (F, state2, H)} somewhere. State should be passed to the controller too :
>>>>
>>>> ...
>>>> controller.nextFilter( newState );
>>>> ...
>>>>
>>>> Pretty theorical at this point... I'm sorry not to have a lot of time to code this, I do realize that for you guys implementing ideas it's a PITA...
>>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>>>
>>> ->   [FSM1] ->   [Filter] ->   [FSM2] ->   [Filter]
>>>
>>> Inside the FSM there could be chains, but there would be one chain per state.
>> Not sure I grok what you say here. There is more than one state, and from each state, you may have more than one transition.
>>
>> Maybe it's just a problem of vocabulary...
>>
>> <theory>
>> In a FSM, you transit from Si to Sj, following a transition Ta, which depends on a context. You may also transit to a state Sk, following a different transition Tb, if the context is different.
>>
>> Selection the transition to follow is all about knowing what's the context is, and in my sample, this was what I call the 'state', which was most certainly an error, as it's clearly a transition. I should have wrote :
>>
>> F --(transition1)-->   G
>> or
>> F --(transition2)-->   H
>>
>> where F, G, H are filters (ore "states")
>>
>> are we on the same page ?
>>
>> </theory>
> Not at all.  :)
>
> Are F, G, H filters inside the FSM or are they external to the FSM?

They are filters in the FSM.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:

> On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>> 
>>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>> 
>>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>   wrote:
>>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>> 
>>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>>>  wrote:
>>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>> 
>>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>> 
>>>>>>>>>> // create the fitler chain for this service
>>>>>>>>>> List<IoFilter>    filters = new ArrayList<IoFilter>();
>>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>> 
>>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>> 
>>>>>>>>>> acceptor.bind(...);
>>>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>>>> 
>>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>>> 
>>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>> 
>>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>> 
>>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>> 
>>>>>>>> About the code in the sandbox :
>>>>>>>> 
>>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>>>> right place ?
>>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>> 
>>>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>>>> you have a concrete use case in mind for that ?
>>>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>>>> would all of this fit into the grand scheme of things?
>>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>> 
>>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>>> : http://s.apache.org/A9W
>>>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>>> I do agree. The proposed solution on http://s.apache.org/A9W is what we currently have, and it's tedious to manage.
>>> 
>>> It would be way better to be able to let the controler call the next filter based on an evaluation method based on the current state.
>>> 
>>> 
>>> Now, the question is : how do the controller knows which filter to call next ? It must have the current state, and it must be able to make the connection.
>>> 
>>> For instance, let's say that from filter F we can switch to either filter G or filter H, depending on the state we transit to in F.
>>> 
>>> F --(state1)-->  G
>>> or
>>> F --(state2)-->  H
>>> 
>>> That means the controller has a map { (F, state1, G), (F, state2, H)} somewhere. State should be passed to the controller too :
>>> 
>>> ...
>>> controller.nextFilter( newState );
>>> ...
>>> 
>>> Pretty theorical at this point... I'm sorry not to have a lot of time to code this, I do realize that for you guys implementing ideas it's a PITA...
>> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>> 
>> ->  [FSM1] ->  [Filter] ->  [FSM2] ->  [Filter]
>> 
>> Inside the FSM there could be chains, but there would be one chain per state.
> Not sure I grok what you say here. There is more than one state, and from each state, you may have more than one transition.
> 
> Maybe it's just a problem of vocabulary...
> 
> <theory>
> In a FSM, you transit from Si to Sj, following a transition Ta, which depends on a context. You may also transit to a state Sk, following a different transition Tb, if the context is different.
> 
> Selection the transition to follow is all about knowing what's the context is, and in my sample, this was what I call the 'state', which was most certainly an error, as it's clearly a transition. I should have wrote :
> 
> F --(transition1)-->  G
> or
> F --(transition2)-->  H
> 
> where F, G, H are filters (ore "states")
> 
> are we on the same page ?
> 
> </theory>

Not at all.  :)

Are F, G, H filters inside the FSM or are they external to the FSM?


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>
>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>
>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>   wrote:
>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>
>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>>   wrote:
>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>
>>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>>>
>>>>>>>>> // create the fitler chain for this service
>>>>>>>>> List<IoFilter>    filters = new ArrayList<IoFilter>();
>>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>>>
>>>>>>>>> acceptor.setFilters(filters);
>>>>>>>>>
>>>>>>>>> acceptor.bind(...);
>>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>>>
>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>>>
>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>>
>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>>
>>>>>>>> acceptor.setFilters(foo);
>>>>>>>>
>>>>>>> About the code in the sandbox :
>>>>>>>
>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>>> right place ?
>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>
>>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>>> you have a concrete use case in mind for that ?
>>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>>> would all of this fit into the grand scheme of things?
>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>>>
>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>> : http://s.apache.org/A9W
>>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>> I do agree. The proposed solution on http://s.apache.org/A9W is what we currently have, and it's tedious to manage.
>>
>> It would be way better to be able to let the controler call the next filter based on an evaluation method based on the current state.
>>
>>
>> Now, the question is : how do the controller knows which filter to call next ? It must have the current state, and it must be able to make the connection.
>>
>> For instance, let's say that from filter F we can switch to either filter G or filter H, depending on the state we transit to in F.
>>
>> F --(state1)-->  G
>> or
>> F --(state2)-->  H
>>
>> That means the controller has a map { (F, state1, G), (F, state2, H)} somewhere. State should be passed to the controller too :
>>
>> ...
>> controller.nextFilter( newState );
>> ...
>>
>> Pretty theorical at this point... I'm sorry not to have a lot of time to code this, I do realize that for you guys implementing ideas it's a PITA...
> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
>
> ->  [FSM1] ->  [Filter] ->  [FSM2] ->  [Filter]
>
> Inside the FSM there could be chains, but there would be one chain per state.
Not sure I grok what you say here. There is more than one state, and 
from each state, you may have more than one transition.

Maybe it's just a problem of vocabulary...

<theory>
In a FSM, you transit from Si to Sj, following a transition Ta, which 
depends on a context. You may also transit to a state Sk, following a 
different transition Tb, if the context is different.

Selection the transition to follow is all about knowing what's the 
context is, and in my sample, this was what I call the 'state', which 
was most certainly an error, as it's clearly a transition. I should have 
wrote :

F --(transition1)-->  G
or
F --(transition2)-->  H

where F, G, H are filters (ore "states")

are we on the same page ?

</theory>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:

> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>> 
>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>  wrote:
>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>> 
>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>>  wrote:
>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>> 
>>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>>> give a list of filter to the service before starting it :
>>>>>>>> 
>>>>>>>> // create the fitler chain for this service
>>>>>>>> List<IoFilter>   filters = new ArrayList<IoFilter>();
>>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>>> filters.add(new MyCodecFilter());
>>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>> 
>>>>>>>> acceptor.setFilters(filters);
>>>>>>>> 
>>>>>>>> acceptor.bind(...);
>>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>> 
>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>> 
>>>>>>> IoFilter foo = new FooFilter();
>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>> IoFilter log = new LogFilter();
>>>>>>> 
>>>>>>> link.addLinkStateListener(foo);
>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>> linkParentWithChild(link, checksum);
>>>>>>> linkParentWithChild(checksum, log);
>>>>>>> 
>>>>>>> acceptor.setFilters(foo);
>>>>>>> 
>>>>>> About the code in the sandbox :
>>>>>> 
>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>>> right place ?
>>>>> Oops, it was meant to just be a sketch.  :)
>>>>> 
>>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>>> you have a concrete use case in mind for that ?
>>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>>> would all of this fit into the grand scheme of things?
>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>> 
>>> Well if it's just for demuxing I proposed few mails ago this solution
>>> : http://s.apache.org/A9W
>> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
> 
> I do agree. The proposed solution on http://s.apache.org/A9W is what we currently have, and it's tedious to manage.
> 
> It would be way better to be able to let the controler call the next filter based on an evaluation method based on the current state.
> 
> 
> Now, the question is : how do the controller knows which filter to call next ? It must have the current state, and it must be able to make the connection.
> 
> For instance, let's say that from filter F we can switch to either filter G or filter H, depending on the state we transit to in F.
> 
> F --(state1)--> G
> or
> F --(state2)--> H
> 
> That means the controller has a map { (F, state1, G), (F, state2, H)} somewhere. State should be passed to the controller too :
> 
> ...
> controller.nextFilter( newState );
> ...
> 
> Pretty theorical at this point... I'm sorry not to have a lot of time to code this, I do realize that for you guys implementing ideas it's a PITA...

I was thinking of a simple DAG some, or all, of the nodes can be FSMs.

-> [FSM1] -> [Filter] -> [FSM2] -> [Filter]

Inside the FSM there could be chains, but there would be one chain per state.  The message would run its course through the chain and then the next state would be set.  Otherwise things become intractable.


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>
>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<el...@gmail.com>  wrote:
>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>
>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>   wrote:
>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>
>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>> give a list of filter to the service before starting it :
>>>>>>>
>>>>>>> // create the fitler chain for this service
>>>>>>> List<IoFilter>   filters = new ArrayList<IoFilter>();
>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>> filters.add(new MyCodecFilter());
>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>
>>>>>>> acceptor.setFilters(filters);
>>>>>>>
>>>>>>> acceptor.bind(...);
>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>
>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>
>>>>>> IoFilter foo = new FooFilter();
>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>> IoFilter log = new LogFilter();
>>>>>>
>>>>>> link.addLinkStateListener(foo);
>>>>>> linkParentWithChild(foo, checksum);
>>>>>> linkParentWithChild(link, checksum);
>>>>>> linkParentWithChild(checksum, log);
>>>>>>
>>>>>> acceptor.setFilters(foo);
>>>>>>
>>>>> About the code in the sandbox :
>>>>>
>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>> right place ?
>>>> Oops, it was meant to just be a sketch.  :)
>>>>
>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>> you have a concrete use case in mind for that ?
>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>> would all of this fit into the grand scheme of things?
>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>
>> Well if it's just for demuxing I proposed few mails ago this solution
>> : http://s.apache.org/A9W
> I think we need to make graphing a 1st class citizen and not buried inside another filter class.

I do agree. The proposed solution on http://s.apache.org/A9W is what we 
currently have, and it's tedious to manage.

It would be way better to be able to let the controler call the next 
filter based on an evaluation method based on the current state.


Now, the question is : how do the controller knows which filter to call 
next ? It must have the current state, and it must be able to make the 
connection.

For instance, let's say that from filter F we can switch to either 
filter G or filter H, depending on the state we transit to in F.

F --(state1)--> G
or
F --(state2)--> H

That means the controller has a map { (F, state1, G), (F, state2, H)} 
somewhere. State should be passed to the controller too :

...
controller.nextFilter( newState );
...

Pretty theorical at this point... I'm sorry not to have a lot of time to 
code this, I do realize that for you guys implementing ideas it's a PITA...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>
>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>
>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>
>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>>  wrote:
>>>>>>
>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>
>>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>>> give a list of filter to the service before starting it :
>>>>>>>
>>>>>>> // create the fitler chain for this service
>>>>>>> List<IoFilter>  filters = new ArrayList<IoFilter>();
>>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>>> filters.add(new MyCodecFilter());
>>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>>>
>>>>>>> acceptor.setFilters(filters);
>>>>>>>
>>>>>>> acceptor.bind(...);
>>>>>>
>>>>>> How do we make chains where two filters feed into one or one filter
>>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>>>
>>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>>>
>>>>>> IoFilter foo = new FooFilter();
>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>> IoFilter log = new LogFilter();
>>>>>>
>>>>>> link.addLinkStateListener(foo);
>>>>>> linkParentWithChild(foo, checksum);
>>>>>> linkParentWithChild(link, checksum);
>>>>>> linkParentWithChild(checksum, log);
>>>>>>
>>>>>> acceptor.setFilters(foo);
>>>>>>
>>>>> About the code in the sandbox :
>>>>>
>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>>> right place ?
>>>>
>>>> Oops, it was meant to just be a sketch.  :)
>>>>
>>>>> About the "filters feed into one or one filter feeds two filters", do
>>>>> you have a concrete use case in mind for that ?
>>>>
>>>> The above example does, Foo and the link state filter.  I'm sure that
>>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>>> would all of this fit into the grand scheme of things?
>>>
>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>
>>
>> Well if it's just for demuxing I proposed few mails ago this solution
>> : http://s.apache.org/A9W
>
> I think we need to make graphing a 1st class citizen and not buried inside another filter class.
>
I think we need to avoid complex feature like graph. IMHO server in
MINA is a codec and an handler 90% of the time. Someone have a use
case which could use filter graph with MINA ?

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:

> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>> 
>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>> 
>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>>  wrote:
>>>>> 
>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>> 
>>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>>> give a list of filter to the service before starting it :
>>>>>> 
>>>>>> // create the fitler chain for this service
>>>>>> List<IoFilter>  filters = new ArrayList<IoFilter>();
>>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>>> filters.add(new MyCodecFilter());
>>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>> 
>>>>>> acceptor.setFilters(filters);
>>>>>> 
>>>>>> acceptor.bind(...);
>>>>> 
>>>>> How do we make chains where two filters feed into one or one filter
>>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>> 
>>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>> 
>>>>> IoFilter foo = new FooFilter();
>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>> IoFilter checksum = new ChecksumFilter();
>>>>> IoFilter log = new LogFilter();
>>>>> 
>>>>> link.addLinkStateListener(foo);
>>>>> linkParentWithChild(foo, checksum);
>>>>> linkParentWithChild(link, checksum);
>>>>> linkParentWithChild(checksum, log);
>>>>> 
>>>>> acceptor.setFilters(foo);
>>>>> 
>>>> About the code in the sandbox :
>>>> 
>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>>> right place ?
>>> 
>>> Oops, it was meant to just be a sketch.  :)
>>> 
>>>> About the "filters feed into one or one filter feeds two filters", do
>>>> you have a concrete use case in mind for that ?
>>> 
>>> The above example does, Foo and the link state filter.  I'm sure that
>>> we've discussed this before.  Another example is a mux/demux situation.  How
>>> would all of this fit into the grand scheme of things?
>> 
>> Yeah, it really should be a graph of filters, not a list of filters.
>> 
> 
> Well if it's just for demuxing I proposed few mails ago this solution
> : http://s.apache.org/A9W

I think we need to make graphing a 1st class citizen and not buried inside another filter class. 


Regards,
Alan

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>
>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>
>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>
>>>  wrote:
>>>>
>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>
>>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>>> give a list of filter to the service before starting it :
>>>>>
>>>>> // create the fitler chain for this service
>>>>> List<IoFilter>  filters = new ArrayList<IoFilter>();
>>>>> filters.add(new LoggingFilter("byte log filter"));
>>>>> filters.add(new MyCodecFilter());
>>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>>> filters.add(newMyProtocolLogicFilter());
>>>>>
>>>>> acceptor.setFilters(filters);
>>>>>
>>>>> acceptor.bind(...);
>>>>
>>>> How do we make chains where two filters feed into one or one filter
>>>> feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>>
>>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>>
>>>> IoFilter foo = new FooFilter();
>>>> LinkStateFilter link = new LinkStateFilter();
>>>> IoFilter checksum = new ChecksumFilter();
>>>> IoFilter log = new LogFilter();
>>>>
>>>> link.addLinkStateListener(foo);
>>>> linkParentWithChild(foo, checksum);
>>>> linkParentWithChild(link, checksum);
>>>> linkParentWithChild(checksum, log);
>>>>
>>>> acceptor.setFilters(foo);
>>>>
>>> About the code in the sandbox :
>>>
>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>>> right place ?
>>
>> Oops, it was meant to just be a sketch.  :)
>>
>>> About the "filters feed into one or one filter feeds two filters", do
>>> you have a concrete use case in mind for that ?
>>
>> The above example does, Foo and the link state filter.  I'm sure that
>> we've discussed this before.  Another example is a mux/demux situation.  How
>> would all of this fit into the grand scheme of things?
>
> Yeah, it really should be a graph of filters, not a list of filters.
>

Well if it's just for demuxing I proposed few mails ago this solution
: http://s.apache.org/A9W

Julien

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>
>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<li...@toolazydogs.com>  wrote:
>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>
>>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>>> give a list of filter to the service before starting it :
>>>>
>>>> // create the fitler chain for this service
>>>> List<IoFilter>  filters = new ArrayList<IoFilter>();
>>>> filters.add(new LoggingFilter("byte log filter"));
>>>> filters.add(new MyCodecFilter());
>>>> filters.add(new LoggingFilter("pojo log filter"));
>>>> filters.add(newMyProtocolLogicFilter());
>>>>
>>>> acceptor.setFilters(filters);
>>>>
>>>> acceptor.bind(...);
>>>
>>> How do we make chains where two filters feed into one or one filter feeds two filters?  If you look in my sandbox we can accommodate this via:
>>>
>>> static import a.m.util.Util. linkParentWithChild; // to be written
>>>
>>> IoFilter foo = new FooFilter();
>>> LinkStateFilter link = new LinkStateFilter();
>>> IoFilter checksum = new ChecksumFilter();
>>> IoFilter log = new LogFilter();
>>>
>>> link.addLinkStateListener(foo);
>>> linkParentWithChild(foo, checksum);
>>> linkParentWithChild(link, checksum);
>>> linkParentWithChild(checksum, log);
>>>
>>> acceptor.setFilters(foo);
>>>
>> About the code in the sandbox :
>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
>> right place ?
> Oops, it was meant to just be a sketch.  :)
>
>> About the "filters feed into one or one filter feeds two filters", do
>> you have a concrete use case in mind for that ?
>
> The above example does, Foo and the link state filter.  I'm sure that we've discussed this before.  Another example is a mux/demux situation.  How would all of this fit into the grand scheme of things?

Yeah, it really should be a graph of filters, not a list of filters.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Wed, Aug 24, 2011 at 6:50 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Aug 24, 2011, at 6:10 AM, Julien Vermillard wrote:
>
>> On Mon, Aug 22, 2011 at 12:17 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>>> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>>>
>>>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>>>
>>>>
>>>>> But i'm feeling more and more confused by the fsm need : as you said some
>>>>> management bits in the session can switch on/off some filters why do we want
>>>>> to complicate the coder 's life using a two state FSM (in the case of
>>>>> multiple filters it would generate  a much more complicated FSM that the
>>>>> coder would have to describe with code ... better ?) ?
>>>>>
>>>>> Do you want the fsm to control the flow between filters (state=filter ?)
>>>>> or do you want your fsm to control if a filter is active ?
>>>>
>>>> There's no reason why one could not have a chain of FSMs.  You get the
>>>> exact same behavior with less framework code.
>>>
>>> The reason why MINA 1 and 2 has a chain is unclear. One possible
>>> explainaition is that MINA was supposed to implement the SEDA architecture
>>> (each filter communicate with the next filter using a queue, and as this
>>> architecture is supposed to spread filters on more than one computer, then
>>> it's easier to implement it using a chain. Well, that's my perception. One
>>> other reason was the lack of vision about the possible use cases. 6 years in
>>> restrospect, I do think that this need never surfaced...
>>>
>>> The more I think about this problem, the more I think that FSM is the way to
>>> go :
>>> - we don't add filters dynamically on a created session
>>> - we *always* know which filter we will call whatever state we are : it's a
>>> protocol we are handling, it's well defined !
>>> - debugging will be easier
>>> - we won't have to use some strange Mutiplexer filter in order to call one
>>> filter or another depending on the message we are dealing with, like it's
>>> currently the case in MINA 2
>>> - coding a protocol will be easier
>>> - we can define @ to declare the FSM, making the developper's life easier
>>> (an idea that needs to be developed...)
>>>
>>> Do we all agree on that ?
>>>
>>
>> If we agree, what we have to do :
>>
>> 1 : we drop the concept of dynamic chains, it's nearly what we have in
>> MINA 3.0 branch
>
> +1
>
>> 2 : dynamic logging filter is dropped too, we will provide another
>> facility for activating logging on incoming/outgoing events
>
> Not sure that this needs to be done out of hand.  I think it might provide some useful features that might be implemented in a different manner.  Something to chat about.
>
>> 3 : we craft an accumulation/decoding framework using (layered ?) FSM
>> for replacing current CodecFilter
>
> Can you provide more detail on what the "accumulation/decoding framework" does and how it works?

Replacing the CumulativeDecoder we actualy have: accumulating enougth
byte until we can convert them to pojos. Like accumulating bytes until
\n\n for decoding a HttpRequest

>
>> 4 : implements a codec using the new framework for validating the
>> design (could be HTTP or LDAP)
>
> +9999 I think we need to have a suite of protocols that we need to implement.  Using these as a guide for our API design and to help judge our implementation would be great.  This is what I am doing in my sandbox.
I have an HTTP implementation undergoing on my PC, but I stopped due
to IoFilter issues.

>
>> 5 : add SSL/TLS at the transport level
>
> Not sure that I'm following

Actualy SSL is a filter and it's really crippled by hacks, Emmanuel
things it should better be handled by NioSocketService or something
like that.

>
>> I can work on 1 & 2 even perhaps on 4 but for 3 I no fan of annotation
>> & generic soup. I'm perhaps a too low level guy for that ;) Someone ?
>
> I regard the characterization of annotations and generics as "soup" as an aesthetic judgment; these technologies clearly have value.  My reply would be some people like to see their stereo and cable TV cables running along the baseboard of their family room and others don't.  ;)
>
>
> Regards,
> Alan
>
>

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 24, 2011, at 6:10 AM, Julien Vermillard wrote:

> On Mon, Aug 22, 2011 at 12:17 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>> 
>>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>> 
>>> 
>>>> But i'm feeling more and more confused by the fsm need : as you said some
>>>> management bits in the session can switch on/off some filters why do we want
>>>> to complicate the coder 's life using a two state FSM (in the case of
>>>> multiple filters it would generate  a much more complicated FSM that the
>>>> coder would have to describe with code ... better ?) ?
>>>> 
>>>> Do you want the fsm to control the flow between filters (state=filter ?)
>>>> or do you want your fsm to control if a filter is active ?
>>> 
>>> There's no reason why one could not have a chain of FSMs.  You get the
>>> exact same behavior with less framework code.
>> 
>> The reason why MINA 1 and 2 has a chain is unclear. One possible
>> explainaition is that MINA was supposed to implement the SEDA architecture
>> (each filter communicate with the next filter using a queue, and as this
>> architecture is supposed to spread filters on more than one computer, then
>> it's easier to implement it using a chain. Well, that's my perception. One
>> other reason was the lack of vision about the possible use cases. 6 years in
>> restrospect, I do think that this need never surfaced...
>> 
>> The more I think about this problem, the more I think that FSM is the way to
>> go :
>> - we don't add filters dynamically on a created session
>> - we *always* know which filter we will call whatever state we are : it's a
>> protocol we are handling, it's well defined !
>> - debugging will be easier
>> - we won't have to use some strange Mutiplexer filter in order to call one
>> filter or another depending on the message we are dealing with, like it's
>> currently the case in MINA 2
>> - coding a protocol will be easier
>> - we can define @ to declare the FSM, making the developper's life easier
>> (an idea that needs to be developed...)
>> 
>> Do we all agree on that ?
>> 
> 
> If we agree, what we have to do :
> 
> 1 : we drop the concept of dynamic chains, it's nearly what we have in
> MINA 3.0 branch

+1

> 2 : dynamic logging filter is dropped too, we will provide another
> facility for activating logging on incoming/outgoing events

Not sure that this needs to be done out of hand.  I think it might provide some useful features that might be implemented in a different manner.  Something to chat about.

> 3 : we craft an accumulation/decoding framework using (layered ?) FSM
> for replacing current CodecFilter

Can you provide more detail on what the "accumulation/decoding framework" does and how it works? 

> 4 : implements a codec using the new framework for validating the
> design (could be HTTP or LDAP)

+9999 I think we need to have a suite of protocols that we need to implement.  Using these as a guide for our API design and to help judge our implementation would be great.  This is what I am doing in my sandbox.

> 5 : add SSL/TLS at the transport level

Not sure that I'm following

> I can work on 1 & 2 even perhaps on 4 but for 3 I no fan of annotation
> & generic soup. I'm perhaps a too low level guy for that ;) Someone ?

I regard the characterization of annotations and generics as "soup" as an aesthetic judgment; these technologies clearly have value.  My reply would be some people like to see their stereo and cable TV cables running along the baseboard of their family room and others don't.  ;)


Regards,
Alan

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Mon, Aug 22, 2011 at 12:17 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>
>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>
>>
>>> But i'm feeling more and more confused by the fsm need : as you said some
>>> management bits in the session can switch on/off some filters why do we want
>>> to complicate the coder 's life using a two state FSM (in the case of
>>> multiple filters it would generate  a much more complicated FSM that the
>>> coder would have to describe with code ... better ?) ?
>>>
>>> Do you want the fsm to control the flow between filters (state=filter ?)
>>> or do you want your fsm to control if a filter is active ?
>>
>> There's no reason why one could not have a chain of FSMs.  You get the
>> exact same behavior with less framework code.
>
> The reason why MINA 1 and 2 has a chain is unclear. One possible
> explainaition is that MINA was supposed to implement the SEDA architecture
> (each filter communicate with the next filter using a queue, and as this
> architecture is supposed to spread filters on more than one computer, then
> it's easier to implement it using a chain. Well, that's my perception. One
> other reason was the lack of vision about the possible use cases. 6 years in
> restrospect, I do think that this need never surfaced...
>
> The more I think about this problem, the more I think that FSM is the way to
> go :
> - we don't add filters dynamically on a created session
> - we *always* know which filter we will call whatever state we are : it's a
> protocol we are handling, it's well defined !
> - debugging will be easier
> - we won't have to use some strange Mutiplexer filter in order to call one
> filter or another depending on the message we are dealing with, like it's
> currently the case in MINA 2
> - coding a protocol will be easier
> - we can define @ to declare the FSM, making the developper's life easier
> (an idea that needs to be developed...)
>
> Do we all agree on that ?
>

If we agree, what we have to do :

1 : we drop the concept of dynamic chains, it's nearly what we have in
MINA 3.0 branch
2 : dynamic logging filter is dropped too, we will provide another
facility for activating logging on incoming/outgoing events
3 : we craft an accumulation/decoding framework using (layered ?) FSM
for replacing current CodecFilter
4 : implements a codec using the new framework for validating the
design (could be HTTP or LDAP)
5 : add SSL/TLS at the transport level

I can work on 1 & 2 even perhaps on 4 but for 3 I no fan of annotation
& generic soup. I'm perhaps a too low level guy for that ;) Someone ?

Julien

Re : [MINA 3.0] filter chains

[Edouard De Oliveira <do...@yahoo.fr>]

On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:


> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> 
>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>> 
>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>> give a list of filter to the service before starting it :
>>> 
>>> // create the fitler chain for this service
>>> List<IoFilter> filters = new ArrayList<IoFilter>();
>>> filters.add(new LoggingFilter("byte log filter"));
>>> filters.add(new MyCodecFilter());
>>> filters.add(new LoggingFilter("pojo log filter"));
>>> filters.add(newMyProtocolLogicFilter());
>>> 
>>> acceptor.setFilters(filters);
>>> 
>>> acceptor.bind(...);
>> 
>> 
>> How do we make chains where two filters feed into one or one filter feeds two filters?  If you look in my sandbox we can accommodate this via:
>> 
>> static import a.m.util.Util. linkParentWithChild; // to be written
>> 
>> IoFilter foo = new FooFilter();
>> LinkStateFilter link = new LinkStateFilter();
>> IoFilter checksum = new ChecksumFilter();
>> IoFilter log = new LogFilter();
>> 
>> link.addLinkStateListener(foo);
>> linkParentWithChild(foo, checksum);
>> linkParentWithChild(link, checksum);
>> linkParentWithChild(checksum, log);
>> 
>> acceptor.setFilters(foo);
>> 
> About the code in the sandbox :
> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
> right place ?

Oops, it was meant to just be a sketch.  :)

> About the "filters feed into one or one filter feeds two filters", do
> you have a concrete use case in mind for that ?


>The above example does, Foo and the link state filter.  I'm sure that we've discussed this before.  Another example is a mux/demux situation.  How would all of this fit into the grand scheme of >things?

>Regards,
>Alan

On my side, besides the @ fsm declaration api (which may be impossible to use as i think it fixes the position of a filter in the chain which is not universal) 
i wrote a simple api i'd like your thoughts on (using the type of syntax used in hibernate criteria) : 

FSMState init = getInitialState();
FSMState b = init.linksTo(FSMStateB.class);
b.linksTo(FSMStateZ.class);

FSMState d = b.linksTo(FSMStateC.class).linksTo(FSMStateD.class);
d.linksTo(FSMStateE.class);
d.linksTo(FSMStateF.class);

which represents obviously :

INIT -> B -> Z
      |-> C -> D -> E
|-> F
wdyt ?

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:

> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> 
>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>> 
>>> I modified the API to remove IoFilterChain. Now you are supposed to
>>> give a list of filter to the service before starting it :
>>> 
>>> // create the fitler chain for this service
>>> List<IoFilter> filters = new ArrayList<IoFilter>();
>>> filters.add(new LoggingFilter("byte log filter"));
>>> filters.add(new MyCodecFilter());
>>> filters.add(new LoggingFilter("pojo log filter"));
>>> filters.add(newMyProtocolLogicFilter());
>>> 
>>> acceptor.setFilters(filters);
>>> 
>>> acceptor.bind(...);
>> 
>> 
>> How do we make chains where two filters feed into one or one filter feeds two filters?  If you look in my sandbox we can accommodate this via:
>> 
>> static import a.m.util.Util. linkParentWithChild; // to be written
>> 
>> IoFilter foo = new FooFilter();
>> LinkStateFilter link = new LinkStateFilter();
>> IoFilter checksum = new ChecksumFilter();
>> IoFilter log = new LogFilter();
>> 
>> link.addLinkStateListener(foo);
>> linkParentWithChild(foo, checksum);
>> linkParentWithChild(link, checksum);
>> linkParentWithChild(checksum, log);
>> 
>> acceptor.setFilters(foo);
>> 
> About the code in the sandbox :
> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
> I see no IoFilter.addLinkStateListener(..) method, am I looking at the
> right place ?

Oops, it was meant to just be a sketch.  :)

> About the "filters feed into one or one filter feeds two filters", do
> you have a concrete use case in mind for that ?


The above example does, Foo and the link state filter.  I'm sure that we've discussed this before.  Another example is a mux/demux situation.  How would all of this fit into the grand scheme of things?


Regards,
Alan

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>
>> I modified the API to remove IoFilterChain. Now you are supposed to
>> give a list of filter to the service before starting it :
>>
>> // create the fitler chain for this service
>> List<IoFilter> filters = new ArrayList<IoFilter>();
>> filters.add(new LoggingFilter("byte log filter"));
>> filters.add(new MyCodecFilter());
>> filters.add(new LoggingFilter("pojo log filter"));
>> filters.add(newMyProtocolLogicFilter());
>>
>> acceptor.setFilters(filters);
>>
>> acceptor.bind(...);
>
>
> How do we make chains where two filters feed into one or one filter feeds two filters?  If you look in my sandbox we can accommodate this via:
>
> static import a.m.util.Util. linkParentWithChild; // to be written
>
> IoFilter foo = new FooFilter();
> IoFilter link = new LinkStateFilter();
> IoFilter checksum = new ChecksumFilter();
> IoFilter log = new LogFilter();
>
> link.addLinkStateListener(foo);
> linkParentWithChild(foo, checksum);
> linkParentWithChild(link, checksum);
> linkParentWithChild(checksum, log);
>
> acceptor.setFilters(foo);
>
About the code in the sandbox :
http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
I see no IoFilter.addLinkStateListener(..) method, am I looking at the
right place ?

About the "filters feed into one or one filter feeds two filters", do
you have a concrete use case in mind for that ?

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:

> I modified the API to remove IoFilterChain. Now you are supposed to
> give a list of filter to the service before starting it :
> 
> // create the fitler chain for this service
> List<IoFilter> filters = new ArrayList<IoFilter>();
> filters.add(new LoggingFilter("byte log filter"));
> filters.add(new MyCodecFilter());
> filters.add(new LoggingFilter("pojo log filter"));
> filters.add(newMyProtocolLogicFilter());
> 
> acceptor.setFilters(filters);
> 
> acceptor.bind(...);


How do we make chains where two filters feed into one or one filter feeds two filters?  If you look in my sandbox we can accommodate this via:

static import a.m.util.Util. linkParentWithChild; // to be written

IoFilter foo = new FooFilter();
IoFilter link = new LinkStateFilter();
IoFilter checksum = new ChecksumFilter();
IoFilter log = new LogFilter();

link.addLinkStateListener(foo);
linkParentWithChild(foo, checksum);
linkParentWithChild(link, checksum);
linkParentWithChild(checksum, log);

acceptor.setFilters(foo);

Re: Re : Re : [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
<do...@yahoo.fr> wrote:
> On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
>
> <do...@yahoo.fr> wrote:
>>
>>
>> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>>
>>>
>>>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>>>>
>>>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
>>>
>>> There's no reason why one could not have a chain of FSMs.  You get the exact same behavior with less framework code.
>>
>>>The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA >architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than >one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the >possible use cases. 6 years in restrospect, I do think that this need never surfaced...
>> With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time
>>
>>>The more I think about this problem, the more I think that FSM is the way to go :
>>>- we don't add filters dynamically on a created session
>>
>>
>>>- we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
>> +1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing
>>
>>>- debugging will be easier
>> i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent
>>
>>>- we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like >it's currently the case in MINA 2
>> not so strange as it is a well known design pattern (Command Pattern)
>>
>>>- coding a protocol will be easier
>> we have to make basic servers easier (or as easy as before) too
>>
>>>- we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)
>>
>>>i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)
>>
>>>for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article >which could be a good base to start with :
>>>http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>>
>>
>> You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
>> http://pastebin.com/CjXjJ2Q1
>>
>>
>>>Do we all agree on that ?
>>>There's lot of momentum on this solution so it should be given at least a try obviously
>>
>
>>+1
>>it's hard for me to figure if it's going to be the solution witout a
>>more complex example implementation
>
>
> it's far from being an implementation it's just a basic poc that a fsm can be built with @
>
>

I modified the API to remove IoFilterChain. Now you are supposed to
give a list of filter to the service before starting it :

// create the fitler chain for this service
List<IoFilter> filters = new ArrayList<IoFilter>();
filters.add(new LoggingFilter("byte log filter"));
filters.add(new MyCodecFilter());
filters.add(new LoggingFilter("pojo log filter"));
filters.add(newMyProtocolLogicFilter());

acceptor.setFilters(filters);

acceptor.bind(...);

Re : Re : [MINA 3.0] filter chains

[Edouard De Oliveira <do...@yahoo.fr>]

On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira

<do...@yahoo.fr> wrote:
>
>
> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>
>>
>>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>>>
>>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
>>
>> There's no reason why one could not have a chain of FSMs.  You get the exact same behavior with less framework code.
>
>>The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA >architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than >one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the >possible use cases. 6 years in restrospect, I do think that this need never surfaced...
> With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time
>
>>The more I think about this problem, the more I think that FSM is the way to go :
>>- we don't add filters dynamically on a created session
>
>
>>- we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
> +1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing
>
>>- debugging will be easier
> i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent
>
>>- we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like >it's currently the case in MINA 2
> not so strange as it is a well known design pattern (Command Pattern)
>
>>- coding a protocol will be easier
> we have to make basic servers easier (or as easy as before) too
>
>>- we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)
>
>>i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)
>
>>for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article >which could be a good base to start with :
>>http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>
>
> You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
> http://pastebin.com/CjXjJ2Q1
>
>
>>Do we all agree on that ?
>>There's lot of momentum on this solution so it should be given at least a try obviously
>

>+1
>it's hard for me to figure if it's going to be the solution witout a
>more complex example implementation


it's far from being an implementation it's just a basic poc that a fsm can be built with @

Re: Re : [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
<do...@yahoo.fr> wrote:
>
>
> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>>
>>
>>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>>>
>>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
>>
>> There's no reason why one could not have a chain of FSMs.  You get the exact same behavior with less framework code.
>
>>The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA >architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than >one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the >possible use cases. 6 years in restrospect, I do think that this need never surfaced...
> With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time
>
>>The more I think about this problem, the more I think that FSM is the way to go :
>>- we don't add filters dynamically on a created session
>
>
>>- we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
> +1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing
>
>>- debugging will be easier
> i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent
>
>>- we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like >it's currently the case in MINA 2
> not so strange as it is a well known design pattern (Command Pattern)
>
>>- coding a protocol will be easier
> we have to make basic servers easier (or as easy as before) too
>
>>- we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)
>
>>i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)
>
>>for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article >which could be a good base to start with :
>>http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
>
>
> You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
> http://pastebin.com/CjXjJ2Q1
>
>
>>Do we all agree on that ?
>>There's lot of momentum on this solution so it should be given at least a try obviously
>

+1
it's hard for me to figure if it's going to be the solution witout a
more complex example implementation

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 24, 2011, at 10:55 AM, Edouard De Oliveira wrote:

> 
> 
> On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
>> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>> 
>> for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article >which could be a good base to start with :
>> http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html
> 
> 
> You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
> http://pastebin.com/CjXjJ2Q1

I like the idea of returning a string to designate the next state.


REgards,
Alan

Re : [MINA 3.0] filter chains

[Edouard De Oliveira <do...@yahoo.fr>]

On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
> 
> 
>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>> 
>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
> 
> There's no reason why one could not have a chain of FSMs.  You get the exact same behavior with less framework code.

>The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA >architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than >one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the >possible use cases. 6 years in restrospect, I do think that this need never surfaced...
With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time

>The more I think about this problem, the more I think that FSM is the way to go :
>- we don't add filters dynamically on a created session


>- we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
+1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing

>- debugging will be easier
i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent

>- we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like >it's currently the case in MINA 2
not so strange as it is a well known design pattern (Command Pattern) 

>- coding a protocol will be easier
we have to make basic servers easier (or as easy as before) too

>- we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)

>i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)

>for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article >which could be a good base to start with :
>http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html


You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions :
http://pastebin.com/CjXjJ2Q1


>Do we all agree on that ?
>There's lot of momentum on this solution so it should be given at least a try obviously

Re : [MINA 3.0] filter chains

[Edouard De Oliveira <do...@yahoo.fr>]

On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
> 
> 
>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>> 
>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
> 
> There's no reason why one could not have a chain of FSMs.  You get the exact same behavior with less framework code.

>The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA >architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than >one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the >possible use cases. 6 years in restrospect, I do think that this need never surfaced...
With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time

>The more I think about this problem, the more I think that FSM is the way to go :
>- we don't add filters dynamically on a created session


>- we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined !
+1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing

>- debugging will be easier
i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent

>- we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like >it's currently the case in MINA 2
not so strange as it is a well known design pattern (Command Pattern) 

>- coding a protocol will be easier
we have to make basic servers easier (or as easy as before) too

>- we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...)

i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously)

for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article which could be a good base to start with :
http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html


>Do we all agree on that ?
There's lot of momentum on this solution so it should be given at least a try obviously

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
> On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
>
>
>> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>>
>> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?
>
> There's no reason why one could not have a chain of FSMs.  You get the exact same behavior with less framework code.

The reason why MINA 1 and 2 has a chain is unclear. One possible 
explainaition is that MINA was supposed to implement the SEDA 
architecture (each filter communicate with the next filter using a 
queue, and as this architecture is supposed to spread filters on more 
than one computer, then it's easier to implement it using a chain. Well, 
that's my perception. One other reason was the lack of vision about the 
possible use cases. 6 years in restrospect, I do think that this need 
never surfaced...

The more I think about this problem, the more I think that FSM is the 
way to go :
- we don't add filters dynamically on a created session
- we *always* know which filter we will call whatever state we are : 
it's a protocol we are handling, it's well defined !
- debugging will be easier
- we won't have to use some strange Mutiplexer filter in order to call 
one filter or another depending on the message we are dealing with, like 
it's currently the case in MINA 2
- coding a protocol will be easier
- we can define @ to declare the FSM, making the developper's life 
easier (an idea that needs to be developed...)

Do we all agree on that ?


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:

> 
> 
> On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:
> 
>> On 8/21/11 2:09 AM, Alan D. Cabrera wrote:
>>> Wow, I totally forgot about these pages.
>>> 
>>> There's been a fair bit of discussion on this topic on the mailing list before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both network endpoints is very hard and dynamic chains make it even more difficult and error prone.  APIs should promote good practices.
>>> 
>>> There are implementation issues as well. Look how complicated the implementation, sketched by Edouard, gets below.
>>> 
>>> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying CoW chains in a library that people already find bewildering.
>>> 
>>> Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up on a regular basis.
>> IMHO, we usually don't need a dynamic chain. There is little to no reason to have it. One objection could be that one may want to inject a log filter on the fly.
> 
>> When one really thinks about it one never just james a log filter in on the fly.  Logging a network endpoint requires a fair bit of thought, where does it go in the chain, where does it >log to, how chatty it is, etc.  Usually, it's always in the chain waiting to be turned on by management bits.  With that said, we're talking about a simple two state FSM, on/off.
> 
> 
> Log is a bad filter example we know it from long ago we should use some instrumentation like tools to make it efficient but something configurable at runtime easily would be even better

My observations also apply to instrumentation as well.

> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
> 
> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?


There's no reason why one could not have a chain of FSMs.  You get the exact same behavior with less framework code.


Regards,
Alan

Re: Re : [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/21/11 8:39 PM, Edouard De Oliveira wrote:
>
> On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:
>
>> On 8/21/11 2:09 AM, Alan D. Cabrera wrote:
>>> Wow, I totally forgot about these pages.
>>>
>>> There's been a fair bit of discussion on this topic on the mailing list before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both network endpoints is very hard and dynamic chains make it even more difficult and error prone.  APIs should promote good practices.
>>>
>>> There are implementation issues as well. Look how complicated the implementation, sketched by Edouard, gets below.
>>>
>>> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying CoW chains in a library that people already find bewildering.
>>>
>>> Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up on a regular basis.
>> IMHO, we usually don't need a dynamic chain. There is little to no reason to have it. One objection could be that one may want to inject a log filter on the fly.
>> When one really thinks about it one never just james a log filter in on the fly.  Logging a network endpoint requires a fair bit of thought, where does it go in the chain, where does it>log to, how chatty it is, etc.  Usually, it's always in the chain waiting to be turned on by management bits.  With that said, we're talking about a simple two state FSM, on/off.
>
> Log is a bad filter example we know it from long ago we should use some instrumentation like tools to make it efficient but something configurable at runtime easily would be even better
>
> But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?
>
> Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?

The FSM obviously will control the flow. The FSM can also check if the 
filter is active, but this is an extra feature, IMHO.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re : [MINA 3.0] filter chains

[Edouard De Oliveira <do...@yahoo.fr>]

On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:

> On 8/21/11 2:09 AM, Alan D. Cabrera wrote:
>> Wow, I totally forgot about these pages.
>> 
>> There's been a fair bit of discussion on this topic on the mailing list before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both network endpoints is very hard and dynamic chains make it even more difficult and error prone.  APIs should promote good practices.
>> 
>> There are implementation issues as well. Look how complicated the implementation, sketched by Edouard, gets below.
>> 
>> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying CoW chains in a library that people already find bewildering.
>> 
>> Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up on a regular basis.
> IMHO, we usually don't need a dynamic chain. There is little to no reason to have it. One objection could be that one may want to inject a log filter on the fly.

>When one really thinks about it one never just james a log filter in on the fly.  Logging a network endpoint requires a fair bit of thought, where does it go in the chain, where does it >log to, how chatty it is, etc.  Usually, it's always in the chain waiting to be turned on by management bits.  With that said, we're talking about a simple two state FSM, on/off.


Log is a bad filter example we know it from long ago we should use some instrumentation like tools to make it efficient but something configurable at runtime easily would be even better

But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate  a much more complicated FSM that the coder would have to describe with code ... better ?) ?

Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ?

> But first, designing a API just to allow such a purpose seems a bit an overkill to me, and second, I wold rather prefer creating a new session, copying an existing one, if we really need to do that.
> 
> MINA 2.0 currently has a this functionality, and frankly, it kills when it comes to debug an application. A debugging session becomes a pain in the butt, as you have to step in an extra layer before going into the next filter.

> Modern IDEs can be configured to not step into code that resides in certain packages.  Just an academic observation.

> If we could ditch this, I would be *very* happy !
> 
> I'll do my Steve Ballmer here : FSM ! FSM ! FSM !

Go baby go!


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lécharny <el...@apache.org>]

On 8/21/11 11:45 PM, Alan D. Cabrera wrote:
> On Aug 21, 2011, at 12:21 PM, Emmanuel Lecharny wrote:
>
>> On 8/21/11 6:25 PM, Alan D. Cabrera wrote:
>>> On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:
>>>
>>> MINA 2.0 currently has a this functionality, and frankly, it kills when it comes to debug an application. A debugging session becomes a pain in the butt, as you have to step in an extra layer before going into the next filter.
>>> Modern IDEs can be configured to not step into code that resides in certain packages.  Just an academic observation.
>> Still a PITA. You *have* to step in when debugging a MINA 2 application, trust me.
> Yeah, maybe a problem for Mina 2 but it doesn't have to be architected that way.  Again, an academic point.  :)

Certainly. And I do think that using a FSM will most certainly help 
debugging.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 21, 2011, at 12:21 PM, Emmanuel Lecharny wrote:

> On 8/21/11 6:25 PM, Alan D. Cabrera wrote:
>> On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:
>> 
>> MINA 2.0 currently has a this functionality, and frankly, it kills when it comes to debug an application. A debugging session becomes a pain in the butt, as you have to step in an extra layer before going into the next filter.
>> Modern IDEs can be configured to not step into code that resides in certain packages.  Just an academic observation.
> Still a PITA. You *have* to step in when debugging a MINA 2 application, trust me.

Yeah, maybe a problem for Mina 2 but it doesn't have to be architected that way.  Again, an academic point.  :)


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/21/11 6:25 PM, Alan D. Cabrera wrote:
> On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:
>
> MINA 2.0 currently has a this functionality, and frankly, it kills when it comes to debug an application. A debugging session becomes a pain in the butt, as you have to step in an extra layer before going into the next filter.
> Modern IDEs can be configured to not step into code that resides in certain packages.  Just an academic observation.
Still a PITA. You *have* to step in when debugging a MINA 2 application, 
trust me.

>
>> If we could ditch this, I would be *very* happy !
>>
>> I'll do my Steve Ballmer here : FSM ! FSM ! FSM !
> Go baby go!
>
>
> Regards,
> Alan
>
>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:

> On 8/21/11 2:09 AM, Alan D. Cabrera wrote:
>> Wow, I totally forgot about these pages.
>> 
>> There's been a fair bit of discussion on this topic on the mailing list before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both network endpoints is very hard and dynamic chains make it even more difficult and error prone.  APIs should promote good practices.
>> 
>> There are implementation issues as well. Look how complicated the implementation, sketched by Edouard, gets below.
>> 
>> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying CoW chains in a library that people already find bewildering.
>> 
>> Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up on a regular basis.
> IMHO, we usually don't need a dynamic chain. There is little to no reason to have it. One objection could be that one may want to inject a log filter on the fly.

When one really thinks about it one never just james a log filter in on the fly.  Logging a network endpoint requires a fair bit of thought, where does it go in the chain, where does it log to, how chatty it is, etc.  Usually, it's always in the chain waiting to be turned on by management bits.  With that said, we're talking about a simple two state FSM, on/off.

> But first, designing a API just to allow such a purpose seems a bit an overkill to me, and second, I wold rather prefer creating a new session, copying an existing one, if we really need to do that.
> 
> MINA 2.0 currently has a this functionality, and frankly, it kills when it comes to debug an application. A debugging session becomes a pain in the butt, as you have to step in an extra layer before going into the next filter.

Modern IDEs can be configured to not step into code that resides in certain packages.  Just an academic observation.

> If we could ditch this, I would be *very* happy !
> 
> I'll do my Steve Ballmer here : FSM ! FSM ! FSM !

Go baby go!


Regards,
Alan

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/21/11 2:09 AM, Alan D. Cabrera wrote:
> Wow, I totally forgot about these pages.
>
> There's been a fair bit of discussion on this topic on the mailing list before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both network endpoints is very hard and dynamic chains make it even more difficult and error prone.  APIs should promote good practices.
>
> There are implementation issues as well. Look how complicated the implementation, sketched by Edouard, gets below.
>
> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying CoW chains in a library that people already find bewildering.
>
> Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up on a regular basis.
IMHO, we usually don't need a dynamic chain. There is little to no 
reason to have it. One objection could be that one may want to inject a 
log filter on the fly. But first, designing a API just to allow such a 
purpose seems a bit an overkill to me, and second, I wold rather prefer 
creating a new session, copying an existing one, if we really need to do 
that.

MINA 2.0 currently has a this functionality, and frankly, it kills when 
it comes to debug an application. A debugging session becomes a pain in 
the butt, as you have to step in an extra layer before going into the 
next filter. If we could ditch this, I would be *very* happy !

I'll do my Steve Ballmer here : FSM ! FSM ! FSM !


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

[Alex Karasulu <ak...@apache.org>]

On Sun, Aug 21, 2011 at 3:09 AM, Alan D. Cabrera <li...@toolazydogs.com>wrote:

> Wow, I totally forgot about these pages.
>
> There's been a fair bit of discussion on this topic on the mailing list
> before, this being the need for dynamically modifying filter chains in a
> session that's already being used.  It is my assertion that it is an
> anti-pattern that signals the need for a state machine.


I think we're confusing different motives for using filters here. One can
add a filter for logging, simulating latency or for actually handling a step
in the IO processing of a protocol message. If it's for handling a step in
IO processing then I can see how the mechanism for doing so can look like
the step of a state machine. However when MINA was originally designed the
filters were intended to handle separate concerns. However the filters are
also being used in such a way that they're not decoupled now, hence the FSM
conversation.


> Getting a protocol right on both network endpoints is very hard and dynamic
> chains make it even more difficult and error prone.  APIs should promote
> good practices.
>

Can you list some of the good practices you have in mind?


>
> There are implementation issues as well. Look how complicated the
> implementation, sketched by Edouard, gets below.
>
>
+1


> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know,
> I've been a strong advocate of thinning Mina's bloated class library.  I
> find it difficult justifying CoW chains in a library that people already
> find bewildering.
>
> Just my 2 cents.  Let's get this finally resolved as this topic seems to
> pop up on a regular basis.
>
>
Yes I agree about getting this finally resolved. However even though I don't
have an answer right now, I think there's a better pattern or combination of
patterns we can use but not all of them need to be exposed by the API.

I think we should be able to inspect, log, or mimic latency in an existing
filter chain dynamically but whether or not this translates to a dynamic
filter chain that's another story.

Best Regards,
-- Alex

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

A chain is a useful thing.  A dynamic chain is merely simulating a FSM, badly IMO.  I propose we drop the idea of dynamic chains.

On Aug 20, 2011, at 11:09 PM, Julien Vermillard wrote:

> So your idea would be to ditch the chain and replace it with a FSM framework ?
> It's what you are trying to implements here ?
> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/state/StateMachineChannel.java

Yes, this is a light sketch of my idea so please review it with a few grains of salt.  :)

It contains several ideas that I'm fleshing out in my mind.

- No session object, values are injected into the filters and states by the framework when a message/event arrives
- No hardcoded cardinality of child or parent endpoints for filters
- Annotations for event handling in state machine
- Strong decoupling of listeners and filters - listener sets are managed by the framework

What you will notice in my sandbox branch is that I am focusing on how protocol implementers would use the framework API while almost totally ignoring the framework's implementation.  I'm looking for efficient clean ease of use of the API from the standpoint of the protocol implementer.  I think the small handful of API interfaces is the bears this out.



Regards,
Alan



> On Sun, Aug 21, 2011 at 2:09 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> Wow, I totally forgot about these pages.
>> 
>> There's been a fair bit of discussion on this topic on the mailing list before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both network endpoints is very hard and dynamic chains make it even more difficult and error prone.  APIs should promote good practices.
>> 
>> There are implementation issues as well. Look how complicated the implementation, sketched by Edouard, gets below.
>> 
>> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying CoW chains in a library that people already find bewildering.
>> 
>> Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up on a regular basis.
>> 
>> 
>> Regards,
>> Alan
>> 
>> On Aug 20, 2011, at 2:10 PM, Julien Vermillard wrote:
>> 
>>> I was thinking about this page :
>>> https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design
>>> 
>>> Look like you have comments about CoW chain, can you please elaborate ?
>>> Julien
>>> 
>>> On Sat, Aug 20, 2011 at 10:29 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>> Consensus?  Really?
>>>> 
>>>> 
>>>> On Aug 20, 2011, at 10:43 AM, Julien Vermillard wrote:
>>>> 
>>>>> Hmm consensus about copy on write chain is already here no ? Wanna try
>>>>> to implements ? ;)
>>>>> 
>>>>> On Sat, Aug 20, 2011 at 1:32 PM, Edouard De Oliveira
>>>>> <do...@yahoo.fr> wrote:
>>>>>> We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ? maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)
>>>>>> 
>>>>>> A copy on write strategy would improve memory footprint. So when would we copy the chain ? when some change happens : add/remove filter
>>>>>> a chain controller could associate to the session it's alternative chain or use the default one.
>>>>>> 
>>>>>> So now what about threads coming into play ? using threadlocal seems a good idea Em
>>>>>> 
>>>>>> So to resume
>>>>>> - copy when necessary
>>>>>> - custom chain should be searched in the following places : threadlocal -> session -> default chain of the controller
>>>>>> 
>>>>>> ChainController.getChain() will hide this whole complexity providing flexibility and efficiency wdyt ?
>>>>>> 
>>>>>> Cordialement, Regards,
>>>>>> -Edouard De Oliveira-
>>>>>> ________________________________
>>>>>> De : Emmanuel Lecharny <el...@gmail.com>
>>>>>> À : dev@mina.apache.org
>>>>>> Envoyé le : Samedi 20 Août 2011 9h29
>>>>>> Objet : Re: [MINA 3.0] filter chains
>>>>>> 
>>>>>> On 8/20/11 8:49 AM, Julien Vermillard 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.
>>>>>> 
>>>>>> The filter chain is copied into the session (at least, it was what was
>>>>>> done for MINA 2). Assuming that two different sessions might use two
>>>>>> different chains, and assumng that the chain might be dynamically
>>>>>> changed, it makes sense to do this copy.
>>>>>> 
>>>>>> Now, if we can split the session (using an executor for instance), then
>>>>>> the chain must be copied. It would make sense to store the chain into a
>>>>>> ThreadLocal variable instead of storing it into a session object.
>>>>>>> 
>>>>>>> Julien
>>>>>>> 
>>>>>>> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>>>>>>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Regards,
>>>>>> Cordialement,
>>>>>> Emmanuel Lécharny
>>>>>> www.iktek.com
>>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

So your idea would be to ditch the chain and replace it with a FSM framework ?
It's what you are trying to implements here ?
http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/state/StateMachineChannel.java

On Sun, Aug 21, 2011 at 2:09 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Wow, I totally forgot about these pages.
>
> There's been a fair bit of discussion on this topic on the mailing list before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both network endpoints is very hard and dynamic chains make it even more difficult and error prone.  APIs should promote good practices.
>
> There are implementation issues as well. Look how complicated the implementation, sketched by Edouard, gets below.
>
> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying CoW chains in a library that people already find bewildering.
>
> Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up on a regular basis.
>
>
> Regards,
> Alan
>
> On Aug 20, 2011, at 2:10 PM, Julien Vermillard wrote:
>
>> I was thinking about this page :
>> https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design
>>
>> Look like you have comments about CoW chain, can you please elaborate ?
>> Julien
>>
>> On Sat, Aug 20, 2011 at 10:29 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>> Consensus?  Really?
>>>
>>>
>>> On Aug 20, 2011, at 10:43 AM, Julien Vermillard wrote:
>>>
>>>> Hmm consensus about copy on write chain is already here no ? Wanna try
>>>> to implements ? ;)
>>>>
>>>> On Sat, Aug 20, 2011 at 1:32 PM, Edouard De Oliveira
>>>> <do...@yahoo.fr> wrote:
>>>>> We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ? maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)
>>>>>
>>>>> A copy on write strategy would improve memory footprint. So when would we copy the chain ? when some change happens : add/remove filter
>>>>> a chain controller could associate to the session it's alternative chain or use the default one.
>>>>>
>>>>> So now what about threads coming into play ? using threadlocal seems a good idea Em
>>>>>
>>>>> So to resume
>>>>> - copy when necessary
>>>>> - custom chain should be searched in the following places : threadlocal -> session -> default chain of the controller
>>>>>
>>>>> ChainController.getChain() will hide this whole complexity providing flexibility and efficiency wdyt ?
>>>>>
>>>>> Cordialement, Regards,
>>>>> -Edouard De Oliveira-
>>>>> ________________________________
>>>>> De : Emmanuel Lecharny <el...@gmail.com>
>>>>> À : dev@mina.apache.org
>>>>> Envoyé le : Samedi 20 Août 2011 9h29
>>>>> Objet : Re: [MINA 3.0] filter chains
>>>>>
>>>>> On 8/20/11 8:49 AM, Julien Vermillard 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.
>>>>>
>>>>> The filter chain is copied into the session (at least, it was what was
>>>>> done for MINA 2). Assuming that two different sessions might use two
>>>>> different chains, and assumng that the chain might be dynamically
>>>>> changed, it makes sense to do this copy.
>>>>>
>>>>> Now, if we can split the session (using an executor for instance), then
>>>>> the chain must be copied. It would make sense to store the chain into a
>>>>> ThreadLocal variable instead of storing it into a session object.
>>>>>>
>>>>>> Julien
>>>>>>
>>>>>> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>>>>>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Cordialement,
>>>>> Emmanuel Lécharny
>>>>> www.iktek.com
>>>>>
>>>
>>>
>
>

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

Wow, I totally forgot about these pages.

There's been a fair bit of discussion on this topic on the mailing list before, this being the need for dynamically modifying filter chains in a session that's already being used.  It is my assertion that it is an anti-pattern that signals the need for a state machine.  Getting a protocol right on both network endpoints is very hard and dynamic chains make it even more difficult and error prone.  APIs should promote good practices.

There are implementation issues as well. Look how complicated the implementation, sketched by Edouard, gets below.  

Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying CoW chains in a library that people already find bewildering.

Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up on a regular basis.


Regards,
Alan

On Aug 20, 2011, at 2:10 PM, Julien Vermillard wrote:

> I was thinking about this page :
> https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design
> 
> Look like you have comments about CoW chain, can you please elaborate ?
> Julien
> 
> On Sat, Aug 20, 2011 at 10:29 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> Consensus?  Really?
>> 
>> 
>> On Aug 20, 2011, at 10:43 AM, Julien Vermillard wrote:
>> 
>>> Hmm consensus about copy on write chain is already here no ? Wanna try
>>> to implements ? ;)
>>> 
>>> On Sat, Aug 20, 2011 at 1:32 PM, Edouard De Oliveira
>>> <do...@yahoo.fr> wrote:
>>>> We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ? maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)
>>>> 
>>>> A copy on write strategy would improve memory footprint. So when would we copy the chain ? when some change happens : add/remove filter
>>>> a chain controller could associate to the session it's alternative chain or use the default one.
>>>> 
>>>> So now what about threads coming into play ? using threadlocal seems a good idea Em
>>>> 
>>>> So to resume
>>>> - copy when necessary
>>>> - custom chain should be searched in the following places : threadlocal -> session -> default chain of the controller
>>>> 
>>>> ChainController.getChain() will hide this whole complexity providing flexibility and efficiency wdyt ?
>>>> 
>>>> Cordialement, Regards,
>>>> -Edouard De Oliveira-
>>>> ________________________________
>>>> De : Emmanuel Lecharny <el...@gmail.com>
>>>> À : dev@mina.apache.org
>>>> Envoyé le : Samedi 20 Août 2011 9h29
>>>> Objet : Re: [MINA 3.0] filter chains
>>>> 
>>>> On 8/20/11 8:49 AM, Julien Vermillard 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.
>>>> 
>>>> The filter chain is copied into the session (at least, it was what was
>>>> done for MINA 2). Assuming that two different sessions might use two
>>>> different chains, and assumng that the chain might be dynamically
>>>> changed, it makes sense to do this copy.
>>>> 
>>>> Now, if we can split the session (using an executor for instance), then
>>>> the chain must be copied. It would make sense to store the chain into a
>>>> ThreadLocal variable instead of storing it into a session object.
>>>>> 
>>>>> Julien
>>>>> 
>>>>> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>>>>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Regards,
>>>> Cordialement,
>>>> Emmanuel Lécharny
>>>> www.iktek.com
>>>> 
>> 
>> 

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

I was thinking about this page :
https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design

Look like you have comments about CoW chain, can you please elaborate ?
Julien

On Sat, Aug 20, 2011 at 10:29 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Consensus?  Really?
>
>
> On Aug 20, 2011, at 10:43 AM, Julien Vermillard wrote:
>
>> Hmm consensus about copy on write chain is already here no ? Wanna try
>> to implements ? ;)
>>
>> On Sat, Aug 20, 2011 at 1:32 PM, Edouard De Oliveira
>> <do...@yahoo.fr> wrote:
>>> We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ? maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)
>>>
>>> A copy on write strategy would improve memory footprint. So when would we copy the chain ? when some change happens : add/remove filter
>>> a chain controller could associate to the session it's alternative chain or use the default one.
>>>
>>> So now what about threads coming into play ? using threadlocal seems a good idea Em
>>>
>>> So to resume
>>> - copy when necessary
>>> - custom chain should be searched in the following places : threadlocal -> session -> default chain of the controller
>>>
>>> ChainController.getChain() will hide this whole complexity providing flexibility and efficiency wdyt ?
>>>
>>> Cordialement, Regards,
>>> -Edouard De Oliveira-
>>> ________________________________
>>> De : Emmanuel Lecharny <el...@gmail.com>
>>> À : dev@mina.apache.org
>>> Envoyé le : Samedi 20 Août 2011 9h29
>>> Objet : Re: [MINA 3.0] filter chains
>>>
>>> On 8/20/11 8:49 AM, Julien Vermillard 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.
>>>
>>> The filter chain is copied into the session (at least, it was what was
>>> done for MINA 2). Assuming that two different sessions might use two
>>> different chains, and assumng that the chain might be dynamically
>>> changed, it makes sense to do this copy.
>>>
>>> Now, if we can split the session (using an executor for instance), then
>>> the chain must be copied. It would make sense to store the chain into a
>>> ThreadLocal variable instead of storing it into a session object.
>>>>
>>>> Julien
>>>>
>>>> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>>>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>
>

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

Consensus?  Really?


On Aug 20, 2011, at 10:43 AM, Julien Vermillard wrote:

> Hmm consensus about copy on write chain is already here no ? Wanna try
> to implements ? ;)
> 
> On Sat, Aug 20, 2011 at 1:32 PM, Edouard De Oliveira
> <do...@yahoo.fr> wrote:
>> We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ? maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)
>> 
>> A copy on write strategy would improve memory footprint. So when would we copy the chain ? when some change happens : add/remove filter
>> a chain controller could associate to the session it's alternative chain or use the default one.
>> 
>> So now what about threads coming into play ? using threadlocal seems a good idea Em
>> 
>> So to resume
>> - copy when necessary
>> - custom chain should be searched in the following places : threadlocal -> session -> default chain of the controller
>> 
>> ChainController.getChain() will hide this whole complexity providing flexibility and efficiency wdyt ?
>> 
>> Cordialement, Regards,
>> -Edouard De Oliveira-
>> ________________________________
>> De : Emmanuel Lecharny <el...@gmail.com>
>> À : dev@mina.apache.org
>> Envoyé le : Samedi 20 Août 2011 9h29
>> Objet : Re: [MINA 3.0] filter chains
>> 
>> On 8/20/11 8:49 AM, Julien Vermillard 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.
>> 
>> The filter chain is copied into the session (at least, it was what was
>> done for MINA 2). Assuming that two different sessions might use two
>> different chains, and assumng that the chain might be dynamically
>> changed, it makes sense to do this copy.
>> 
>> Now, if we can split the session (using an executor for instance), then
>> the chain must be copied. It would make sense to store the chain into a
>> ThreadLocal variable instead of storing it into a session object.
>>> 
>>> Julien
>>> 
>>> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>>> 
>> 
>> 
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>> 

Re: Re : [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

Hmm consensus about copy on write chain is already here no ? Wanna try
to implements ? ;)

On Sat, Aug 20, 2011 at 1:32 PM, Edouard De Oliveira
<do...@yahoo.fr> wrote:
> We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ? maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)
>
> A copy on write strategy would improve memory footprint. So when would we copy the chain ? when some change happens : add/remove filter
> a chain controller could associate to the session it's alternative chain or use the default one.
>
> So now what about threads coming into play ? using threadlocal seems a good idea Em
>
> So to resume
> - copy when necessary
> - custom chain should be searched in the following places : threadlocal -> session -> default chain of the controller
>
> ChainController.getChain() will hide this whole complexity providing flexibility and efficiency wdyt ?
>
> Cordialement, Regards,
> -Edouard De Oliveira-
> ________________________________
> De : Emmanuel Lecharny <el...@gmail.com>
> À : dev@mina.apache.org
> Envoyé le : Samedi 20 Août 2011 9h29
> Objet : Re: [MINA 3.0] filter chains
>
> On 8/20/11 8:49 AM, Julien Vermillard 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.
>
> The filter chain is copied into the session (at least, it was what was
> done for MINA 2). Assuming that two different sessions might use two
> different chains, and assumng that the chain might be dynamically
> changed, it makes sense to do this copy.
>
> Now, if we can split the session (using an executor for instance), then
> the chain must be copied. It would make sense to store the chain into a
> ThreadLocal variable instead of storing it into a session object.
>>
>> Julien
>>
>> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

Re : [MINA 3.0] filter chains

[Edouard De Oliveira <do...@yahoo.fr>]

We shouldn't systematically copy the chain in the session as imho it's not so usual to dynamically add filters in one particular session (the first case that comes to my mind is dynamically protecting the session with ssl but it requires a new connection most of the time no ? maybe some dynamic compression or some negociation mechanism that will need a particular filter wrapping and unwrapping messages)

A copy on write strategy would improve memory footprint. So when would we copy the chain ? when some change happens : add/remove filter 
a chain controller could associate to the session it's alternative chain or use the default one.

So now what about threads coming into play ? using threadlocal seems a good idea Em

So to resume 
- copy when necessary
- custom chain should be searched in the following places : threadlocal -> session -> default chain of the controller

ChainController.getChain() will hide this whole complexity providing flexibility and efficiency wdyt ? 
 
Cordialement, Regards,
-Edouard De Oliveira-
________________________________
De : Emmanuel Lecharny <el...@gmail.com>
À : dev@mina.apache.org
Envoyé le : Samedi 20 Août 2011 9h29
Objet : Re: [MINA 3.0] filter chains

On 8/20/11 8:49 AM, Julien Vermillard 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.

The filter chain is copied into the session (at least, it was what was 
done for MINA 2). Assuming that two different sessions might use two 
different chains, and assumng that the chain might be dynamically 
changed, it makes sense to do this copy.

Now, if we can split the session (using an executor for instance), then 
the chain must be copied. It would make sense to store the chain into a 
ThreadLocal variable instead of storing it into a session object.
>
> Julien
>
> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

[Emmanuel Lecharny <el...@gmail.com>]

On 8/20/11 8:49 AM, Julien Vermillard 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.

The filter chain is copied into the session (at least, it was what was 
done for MINA 2). Assuming that two different sessions might use two 
different chains, and assumng that the chain might be dynamically 
changed, it makes sense to do this copy.

Now, if we can split the session (using an executor for instance), then 
the chain must be copied. It would make sense to store the chain into a 
ThreadLocal variable instead of storing it into a session object.
>
> Julien
>
> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<li...@toolazydogs.com>  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
>>> <jv...@gmail.com>  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<st...@proemion.com>  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:jvermillard@gmail.com] 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
>>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

Yeah, I smell implementation leaking into API.  I, as a filter in a chain, should not care what my index is in the grand scheme of things.


Regards,
Alan

On Aug 19, 2011, at 11:49 PM, Julien Vermillard 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 <li...@toolazydogs.com> 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
>>> <jv...@gmail.com> 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 <st...@proemion.com> 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:jvermillard@gmail.com] 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
>>>> 
>> 
>> 

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

I guess one of the things that I'm truing to understand is why do we need that index?  Why should that be exposed to the filter implementer?


Regards,
Alan

On Aug 19, 2011, at 11:56 PM, Julien Vermillard wrote:

> 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
> <jv...@gmail.com> 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 <li...@toolazydogs.com> 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
>>>> <jv...@gmail.com> 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 <st...@proemion.com> 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:jvermillard@gmail.com] 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
>>>>> 
>>> 
>>> 
>> 

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

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
<jv...@gmail.com> 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 <li...@toolazydogs.com> 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
>>> <jv...@gmail.com> 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 <st...@proemion.com> 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:jvermillard@gmail.com] 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
>>>>
>>
>>
>

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

Thanks,got it, I Will try to implement that tomorrow.
--
Julien Vermillard


Le 20 août 2011 à 09:30, Emmanuel Lecharny <el...@gmail.com> a
écrit :

> On 8/20/11 8:49 AM, Julien Vermillard 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.
>
> The filter chain is copied into the session (at least, it was what was
> done for MINA 2). Assuming that two different sessions might use two
> different chains, and assumng that the chain might be dynamically
> changed, it makes sense to do this copy.
>
> Now, if we can split the session (using an executor for instance),
> then
> the chain must be copied. It would make sense to store the chain
> into a
> ThreadLocal variable instead of storing it into a session object.
>>
>> Julien
>>
>> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<list@toolazydogs.com
>> >  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
>>>> <jv...@gmail.com>  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<steve.ulrich@proemion.com
>>>>> >  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:jvermillard@gmail.com] 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
>>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

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 <li...@toolazydogs.com> 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
>> <jv...@gmail.com> 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 <st...@proemion.com> 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:jvermillard@gmail.com] 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
>>>
>
>

Re: [MINA 3.0] filter chains

["Alan D. Cabrera" <li...@toolazydogs.com>]

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
> <jv...@gmail.com> 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 <st...@proemion.com> 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:jvermillard@gmail.com] 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
>> 

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

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
<jv...@gmail.com> 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 <st...@proemion.com> 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:jvermillard@gmail.com] 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
>

Re: [MINA 3.0] filter chains

[Julien Vermillard <jv...@gmail.com>]

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 <st...@proemion.com> 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:jvermillard@gmail.com] 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

AW: [MINA 3.0] filter chains

[Steve Ulrich <st...@proemion.com>]

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:jvermillard@gmail.com] 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
>