Re: [MINA 3.0] filter chains
On Mon, Aug 22, 2011 at 12:17 AM, Emmanuel Lecharny elecha...@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
trunk as 3.0 ?
Hi, Since 2.X dev are done in specific branches, I would like to move 3.0 dev from the 3.0 branch to trunk for giving it more visibility. WDYT ? Julien
Re: [MINA 3.0] filter chains
On Aug 24, 2011, at 6:10 AM, Julien Vermillard wrote: On Mon, Aug 22, 2011 at 12:17 AM, Emmanuel Lecharny elecha...@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) + 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
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: trunk as 3.0 ?
On Wed, Aug 24, 2011 at 3:12 PM, Julien Vermillard jvermill...@gmail.com wrote: Since 2.X dev are done in specific branches, I would like to move 3.0 dev from the 3.0 branch to trunk for giving it more visibility. +1 /niklas
Re: [MINA 3.0] filter chains
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
On Wed, Aug 24, 2011 at 6:50 PM, Alan D. Cabrera l...@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 elecha...@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) + 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: trunk as 3.0 ?
On 8/24/11 9:09 PM, Niklas Gustavsson wrote: On Wed, Aug 24, 2011 at 3:12 PM, Julien Vermillard jvermill...@gmail.com wrote: Since 2.X dev are done in specific branches, I would like to move 3.0 dev from the 3.0 branch to trunk for giving it more visibility. +1 /niklas Go ahead -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: trunk as 3.0 ?
Sounds good. Regards, Alan On Aug 24, 2011, at 6:12 AM, Julien Vermillard wrote: Hi, Since 2.X dev are done in specific branches, I would like to move 3.0 dev from the 3.0 branch to trunk for giving it more visibility. WDYT ? Julien
Re : trunk as 3.0 ?
Sounds ok Cordialement, Regards, -Edouard De Oliveira- On Aug 24, 2011, at 6:12 AM, Julien Vermillard wrote: Hi, Since 2.X dev are done in specific branches, I would like to move 3.0 dev from the 3.0 branch to trunk for giving it more visibility. WDYT ? Julien
Re: Re : [MINA 3.0] filter chains
On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira doe_wan...@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
