You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@apache.org> on 2009/06/10 21:37:10 UTC
[MINA 3.0] Preliminary thoughts.
Hi guys,
as I'm commuting every day for a long distance, I have had time to think
about what I would see in MINA 3.0. Here is the result of my random
thoughts....
Mina 3.0 design and expected features
-------------------------------------
- selectors usage
We should be able to define the number of selectors to use, and to
define what they will be used for. For instance, atm, we have a selector
in the Acceptor, plus a selector per Processor. This is not necessarily
the best solution.
* do some perf tests to see if it's better to use one or many selectors.
* decouple the selector usage from the the selector definition. It
should be possible to define one single selector and use it in many places
* the Acceptor and Processor should not necessarily be associated with a
thread. it's up to the user to define the thread model to use
- Chain
The current chain implemention is cumbersome. We would like to have
something easier to manipluate, and also easier to debug.
* the chain should be optionally dynamic : a session can add a new
filter in the chain whenever needed
* we should not always copy the chain in each session, if the chain is
immutable
* however, it should be possible to change the global chain without
breaking the processing.
* we should have one chain for incoming messages, and another one for
outgoing messages
* it should be possible to have a multi-stage codec (ie, add more than
one codec filter in the chain)
* we should allow a queuing mechanism to be put in between each filters
* the Head and Tail filters are useless : they should be removed
* a chain may not be a list of filters. It can be a graph
- Filters
* a filter should accept a stream<Object>, the Object can change from
one filter to another. it's up to the user to correctly handle the Object.
* the executor filter could be present in moe than one place in the
chain (SEDA)
* statistic must be established with a filter
* we should define two interfaces for filters : IngoingFilter and
OutgoingFilter. They will expose the methods to process ingoing and
outgoing messages
- Session
* we should have two kind of sessions : statefull and stateless.
Sometime, we don't need to store any kind of information in a session
* we should add a sessionManager instead of all the existing queues used
to manage the dead sessions, the idle sessions, etc.
* session should not necessarily be associated with a processor.
* If a session is statefull, then we should attach the data to the
channel instead of creating a map for that
* A session must be attached to an acceptor, allowing more than one
chain if the acceptor is to deal with more than one single SocketServer
- codec
* we don't have stateful or stateless codecs. We should distinguish the
two kinds of codec someone can use.
* we should efine a collection of existing codecs
* as we can handle more than one protocol, we must add a demuxingCodec
which point to the next filter, conditionally
- Buffer
* We should not wrap ByteBuffer into our own IoBuffer class. We should
have a list of ByteBuffers instead, containing all the ByteBuffers.
- General
* offer a NIO 2.0 library
This is just a starting point ... Feel free to comment, add or remove
some items !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re : [MINA 3.0] Preliminary thoughts.
Posted by Edouard De Oliveira <do...@yahoo.fr>.
+1
Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php
----- Message d'origine ----
De : Julien Vermillard <jv...@archean.fr>
À : dev@mina.apache.org
Envoyé le : Vendredi, 12 Juin 2009, 15h51mn 10s
Objet : Re: [MINA 3.0] Preliminary thoughts.
Real blocker are to fix the remaining bugs in JIRA and we are done.
Julien
Le Fri, 12 Jun 2009 07:07:06 -0400,
Mark Webb <el...@gmail.com> a écrit :
> Between work and school, I have been really busy. I have been keeping
> up with the mailing list, but not doing much with the code. Things
> are starting to shake loose for me, so I will be able to jump back in
> now.
>
> What do you see as the major roadblocks to releasing 2.0?
>
>
> On Fri, Jun 12, 2009 at 3:34 AM, Emmanuel
> Lecharny<el...@apache.org> wrote:
> > Mark Webb wrote:
> >>
> >> What are the plans for release of 2.0 and the migration to a 3.0
> >> development? Is anyone prototyping any of these ideas in
> >> sandboxes?
> >>
> >
> > Hi Mark,
> >
> > those are just random thoughts I put down on the site after having
> > posted them to the list. I wrote them during my long commute from
> > house to my client's office.
> >
> > Right now, there is nothing started, except a few experiment in some
> > branches
> > (https://svn.apache.org/repos/asf/mina/branches/mina-new-chain2 )
> > done a few months ago.
> >
> > The main target is still to get MINA 2.0 out asap, and it takes
> > forever, because a few peeps are working on it, something I can
> > understand. MINA 2.0 code is far from being perfect, and it's not
> > very funny to try to fix bugs in it, as the inner documentation is
> > pretty sparse, and you have to double guess what some portion of
> > the code is supposed to do before trying to fix it.
> >
> > My idea, when I posted this 3.0 mail, was to try to get more
> > excitation from all of the people musing around MINA. It's always
> > fun to start a new version, and it's most certainly useful to see
> > what people have in mind, instead of going forward, code and commit.
> >
> > It will take a couple of months before MINA 2.0 will be released
> > (after a couple of RC), and I think we are close to the final
> > version. Seems to be good timing to start thinking seriously about
> > MINA 3.0 !
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >
Re: [MINA 3.0] Preliminary thoughts.
Posted by Julien Vermillard <jv...@archean.fr>.
Real blocker are to fix the remaining bugs in JIRA and we are done.
Julien
Le Fri, 12 Jun 2009 07:07:06 -0400,
Mark Webb <el...@gmail.com> a écrit :
> Between work and school, I have been really busy. I have been keeping
> up with the mailing list, but not doing much with the code. Things
> are starting to shake loose for me, so I will be able to jump back in
> now.
>
> What do you see as the major roadblocks to releasing 2.0?
>
>
> On Fri, Jun 12, 2009 at 3:34 AM, Emmanuel
> Lecharny<el...@apache.org> wrote:
> > Mark Webb wrote:
> >>
> >> What are the plans for release of 2.0 and the migration to a 3.0
> >> development? Is anyone prototyping any of these ideas in
> >> sandboxes?
> >>
> >
> > Hi Mark,
> >
> > those are just random thoughts I put down on the site after having
> > posted them to the list. I wrote them during my long commute from
> > house to my client's office.
> >
> > Right now, there is nothing started, except a few experiment in some
> > branches
> > (https://svn.apache.org/repos/asf/mina/branches/mina-new-chain2 )
> > done a few months ago.
> >
> > The main target is still to get MINA 2.0 out asap, and it takes
> > forever, because a few peeps are working on it, something I can
> > understand. MINA 2.0 code is far from being perfect, and it's not
> > very funny to try to fix bugs in it, as the inner documentation is
> > pretty sparse, and you have to double guess what some portion of
> > the code is supposed to do before trying to fix it.
> >
> > My idea, when I posted this 3.0 mail, was to try to get more
> > excitation from all of the people musing around MINA. It's always
> > fun to start a new version, and it's most certainly useful to see
> > what people have in mind, instead of going forward, code and commit.
> >
> > It will take a couple of months before MINA 2.0 will be released
> > (after a couple of RC), and I think we are close to the final
> > version. Seems to be good timing to start thinking seriously about
> > MINA 3.0 !
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >
Re: [MINA 3.0] Preliminary thoughts.
Posted by Mark Webb <el...@gmail.com>.
Between work and school, I have been really busy. I have been keeping
up with the mailing list, but not doing much with the code. Things
are starting to shake loose for me, so I will be able to jump back in
now.
What do you see as the major roadblocks to releasing 2.0?
On Fri, Jun 12, 2009 at 3:34 AM, Emmanuel Lecharny<el...@apache.org> wrote:
> Mark Webb wrote:
>>
>> What are the plans for release of 2.0 and the migration to a 3.0
>> development? Is anyone prototyping any of these ideas in sandboxes?
>>
>
> Hi Mark,
>
> those are just random thoughts I put down on the site after having posted
> them to the list. I wrote them during my long commute from house to my
> client's office.
>
> Right now, there is nothing started, except a few experiment in some
> branches (https://svn.apache.org/repos/asf/mina/branches/mina-new-chain2 )
> done a few months ago.
>
> The main target is still to get MINA 2.0 out asap, and it takes forever,
> because a few peeps are working on it, something I can understand. MINA 2.0
> code is far from being perfect, and it's not very funny to try to fix bugs
> in it, as the inner documentation is pretty sparse, and you have to double
> guess what some portion of the code is supposed to do before trying to fix
> it.
>
> My idea, when I posted this 3.0 mail, was to try to get more excitation from
> all of the people musing around MINA. It's always fun to start a new
> version, and it's most certainly useful to see what people have in mind,
> instead of going forward, code and commit.
>
> It will take a couple of months before MINA 2.0 will be released (after a
> couple of RC), and I think we are close to the final version. Seems to be
> good timing to start thinking seriously about MINA 3.0 !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [MINA 3.0] Preliminary thoughts.
Posted by Emmanuel Lecharny <el...@apache.org>.
Mark Webb wrote:
> What are the plans for release of 2.0 and the migration to a 3.0
> development? Is anyone prototyping any of these ideas in sandboxes?
>
Hi Mark,
those are just random thoughts I put down on the site after having
posted them to the list. I wrote them during my long commute from house
to my client's office.
Right now, there is nothing started, except a few experiment in some
branches (https://svn.apache.org/repos/asf/mina/branches/mina-new-chain2
) done a few months ago.
The main target is still to get MINA 2.0 out asap, and it takes forever,
because a few peeps are working on it, something I can understand. MINA
2.0 code is far from being perfect, and it's not very funny to try to
fix bugs in it, as the inner documentation is pretty sparse, and you
have to double guess what some portion of the code is supposed to do
before trying to fix it.
My idea, when I posted this 3.0 mail, was to try to get more excitation
from all of the people musing around MINA. It's always fun to start a
new version, and it's most certainly useful to see what people have in
mind, instead of going forward, code and commit.
It will take a couple of months before MINA 2.0 will be released (after
a couple of RC), and I think we are close to the final version. Seems to
be good timing to start thinking seriously about MINA 3.0 !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [MINA 3.0] Preliminary thoughts.
Posted by Mark Webb <el...@gmail.com>.
What are the plans for release of 2.0 and the migration to a 3.0
development? Is anyone prototyping any of these ideas in sandboxes?
On Thu, Jun 11, 2009 at 7:55 AM, Emmanuel Lecharny<el...@apache.org> wrote:
> I have created a Wiki page containing this discussion :
> http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design
>
> Julien Vermillard wrote:
>>
>> Hi,
>> reply inline
>>
>> Le Wed, 10 Jun 2009 21:37:10 +0200,
>> Emmanuel Lecharny <el...@apache.org> a écrit :
>>
>>
>>>
>>> Hi guys,
>>>
>>> as I'm commuting every day for a long distance, I have had time to
>>> think about what I would see in MINA 3.0. Here is the result of my
>>> random thoughts....
>>>
>>
>> And not see anymore ;)
>>
>>
>>>
>>> Mina 3.0 design and expected features
>>> -------------------------------------
>>>
>>> - selectors usage
>>> We should be able to define the number of selectors to use, and to define
>>> what they will be used for. For instance, atm, we have a
>>> selector in the Acceptor, plus a selector per Processor. This is not
>>> necessarily the best solution.
>>>
>>
>>
>>>
>>> * do some perf tests to see if it's better to use one or many
>>> selectors.
>>> * decouple the selector usage from the the selector definition. It should
>>> be possible to define one single selector and use it in many
>>> places
>>> * the Acceptor and Processor should not necessarily be associated
>>> with a thread. it's up to the user to define the thread model to use
>>>
>>
>> Actually look like we need different strategy for different usage. On the
>> right threading/selector strategy look like there is no real
>> consensus and we will need to experiment for finding the default
>> solution.
>>
>>
>>>
>>> - Chain
>>> The current chain implemention is cumbersome. We would like to have
>>> something easier to manipluate, and also easier to debug.
>>>
>>> * the chain should be optionally dynamic : a session can add a new filter
>>> in the chain whenever needed
>>> * we should not always copy the chain in each session, if the chain
>>> is immutable
>>>
>>
>> Yes, cause most of time we configure the chain on the acceptor and
>> never change it again.
>> Look like we agreed on copy-on-write for that.
>>
>>
>>>
>>> * however, it should be possible to change the global chain without
>>> breaking the processing.
>>> * we should have one chain for incoming messages, and another one for
>>> outgoing messages
>>> * it should be possible to have a multi-stage codec (ie, add more
>>> than one codec filter in the chain)
>>>
>>
>> Mandatory, it's very often I use a TextLineCodec and a String-to-Pojo
>> filter, and I'm sure I'm not alone.
>>
>>
>>>
>>> * we should allow a queuing mechanism to be put in between each
>>> filters
>>>
>>
>> What is that for ? Look like you got a new idea :)
>>
>>
>>>
>>> * the Head and Tail filters are useless : they should be removed
>>>
>>
>> Yes
>>
>>
>>>
>>> * a chain may not be a list of filters. It can be a graph
>>>
>>
>> If we can keep the API simple enough, why not.
>>
>>
>>>
>>> - Filters
>>>
>>> * a filter should accept a stream<Object>, the Object can change from one
>>> filter to another. it's up to the user to correctly handle the
>>> Object.
>>>
>>
>> You want to say multi layer codec ?
>>
>>
>>>
>>> * the executor filter could be present in moe than one place in the chain
>>> (SEDA)
>>>
>>
>> Mandatory if someone really want SEDA.
>>
>>
>>>
>>> * statistic must be established with a filter
>>>
>>
>> Again mandatory.
>> You won't do stats the same way on HTTP or FTP and stats can be very
>> costy.
>>
>>
>>>
>>> * we should define two interfaces for filters : IngoingFilter and
>>> OutgoingFilter. They will expose the methods to process ingoing and outgoing
>>> messages
>>>
>>
>> The question is where to put sessionOpen/Closed/Idle in a two chains
>> model.
>>
>>
>>>
>>> - Session
>>> * we should have two kind of sessions : statefull and stateless.
>>> Sometime, we don't need to store any kind of information in a session
>>>
>>
>> If we create the HashMap on first additon, where is the gain ?
>>
>>
>>>
>>> * we should add a sessionManager instead of all the existing queues
>>> used to manage the dead sessions, the idle sessions, etc.
>>>
>>
>> We need to rethink the whole separation between IoProcessor and
>> IoService and where we manage closing/accepting queues.
>>
>>
>>>
>>> * session should not necessarily be associated with a processor.
>>>
>>
>> +1
>>
>>
>>>
>>> * If a session is statefull, then we should attach the data to the
>>> channel instead of creating a map for that
>>>
>>
>> Can you say more about that, where is the gain ?
>>
>>
>>>
>>> * A session must be attached to an acceptor, allowing more than one chain
>>> if the acceptor is to deal with more than one single
>>> SocketServer
>>>
>>
>> We need to find away for running more than 1 kind of port/protocol with
>> the same set of Thread/Executors. I suppose it would be interesting
>> for ADS. On my side I run servers with 3 or 4 SocketAcceptors for
>> different protocols, somthing like 10 SocketConnectors for different
>> protocols.
>> Perfs aren't an issue for me actually, be it can change.
>>
>>>
>>> - codec
>>> * we don't have stateful or stateless codecs. We should distinguish
>>> the two kinds of codec someone can use.
>>>
>>
>> +1
>>
>>
>>>
>>> * we should efine a collection of existing codecs
>>>
>>
>> For that we need a standard way of doing a codec on the Pojo side.
>> I'm sure LDAP pjo oof ADs are very different (and got different
>> dependencies) of the one of Asyncweb or Vysper.
>>
>>
>>>
>>> * as we can handle more than one protocol, we must add a
>>> demuxingCodec which point to the next filter, conditionally
>>>
>>
>> Here the graph ? :)
>>
>>
>>>
>>> - Buffer
>>> * We should not wrap ByteBuffer into our own IoBuffer class. We
>>> should have a list of ByteBuffers instead, containing all the
>>> ByteBuffers.
>>>
>>
>> And some extended Stream interface for manipulation.
>>
>>>
>>> - General
>>> * offer a NIO 2.0 library
>>>
>>>
>>
>> Well it's going to be soon mandatory :)
>>
>>>
>>> This is just a starting point ... Feel free to comment, add or remove
>>> some items !
>>>
>>>
>>
>> We need at first a great test platform for testing the different
>> protocols and implementation ideas (Thread/Selector/Channel
>> strategies). So we make choice based on facts for the engine.
>>
>> Julien
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [MINA 3.0] Preliminary thoughts.
Posted by Emmanuel Lecharny <el...@apache.org>.
I have created a Wiki page containing this discussion :
http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design
Julien Vermillard wrote:
> Hi,
> reply inline
>
> Le Wed, 10 Jun 2009 21:37:10 +0200,
> Emmanuel Lecharny <el...@apache.org> a écrit :
>
>
>> Hi guys,
>>
>> as I'm commuting every day for a long distance, I have had time to
>> think about what I would see in MINA 3.0. Here is the result of my
>> random thoughts....
>>
>
> And not see anymore ;)
>
>
>> Mina 3.0 design and expected features
>> -------------------------------------
>>
>> - selectors usage
>> We should be able to define the number of selectors to use, and to
>> define what they will be used for. For instance, atm, we have a
>> selector in the Acceptor, plus a selector per Processor. This is not
>> necessarily the best solution.
>>
>
>
>> * do some perf tests to see if it's better to use one or many
>> selectors.
>> * decouple the selector usage from the the selector definition. It
>> should be possible to define one single selector and use it in many
>> places
>> * the Acceptor and Processor should not necessarily be associated
>> with a thread. it's up to the user to define the thread model to use
>>
>
> Actually look like we need different strategy for different usage.
> On the right threading/selector strategy look like there is no real
> consensus and we will need to experiment for finding the default
> solution.
>
>
>> - Chain
>> The current chain implemention is cumbersome. We would like to have
>> something easier to manipluate, and also easier to debug.
>>
>> * the chain should be optionally dynamic : a session can add a new
>> filter in the chain whenever needed
>> * we should not always copy the chain in each session, if the chain
>> is immutable
>>
>
> Yes, cause most of time we configure the chain on the acceptor and
> never change it again.
> Look like we agreed on copy-on-write for that.
>
>
>> * however, it should be possible to change the global chain without
>> breaking the processing.
>> * we should have one chain for incoming messages, and another one for
>> outgoing messages
>> * it should be possible to have a multi-stage codec (ie, add more
>> than one codec filter in the chain)
>>
> Mandatory, it's very often I use a TextLineCodec and a String-to-Pojo
> filter, and I'm sure I'm not alone.
>
>
>> * we should allow a queuing mechanism to be put in between each
>> filters
>>
> What is that for ? Look like you got a new idea :)
>
>
>> * the Head and Tail filters are useless : they should be removed
>>
> Yes
>
>
>> * a chain may not be a list of filters. It can be a graph
>>
> If we can keep the API simple enough, why not.
>
>
>> - Filters
>>
>> * a filter should accept a stream<Object>, the Object can change from
>> one filter to another. it's up to the user to correctly handle the
>> Object.
>>
>
> You want to say multi layer codec ?
>
>
>> * the executor filter could be present in moe than one place in the
>> chain (SEDA)
>>
>
> Mandatory if someone really want SEDA.
>
>
>> * statistic must be established with a filter
>>
> Again mandatory.
> You won't do stats the same way on HTTP or FTP and stats can be very
> costy.
>
>
>> * we should define two interfaces for filters : IngoingFilter and
>> OutgoingFilter. They will expose the methods to process ingoing and
>> outgoing messages
>>
>
> The question is where to put sessionOpen/Closed/Idle in a two chains
> model.
>
>
>> - Session
>> * we should have two kind of sessions : statefull and stateless.
>> Sometime, we don't need to store any kind of information in a session
>>
> If we create the HashMap on first additon, where is the gain ?
>
>
>> * we should add a sessionManager instead of all the existing queues
>> used to manage the dead sessions, the idle sessions, etc.
>>
> We need to rethink the whole separation between IoProcessor and
> IoService and where we manage closing/accepting queues.
>
>
>> * session should not necessarily be associated with a processor.
>>
> +1
>
>
>> * If a session is statefull, then we should attach the data to the
>> channel instead of creating a map for that
>>
> Can you say more about that, where is the gain ?
>
>
>> * A session must be attached to an acceptor, allowing more than one
>> chain if the acceptor is to deal with more than one single
>> SocketServer
>>
> We need to find away for running more than 1 kind of port/protocol with
> the same set of Thread/Executors. I suppose it would be interesting
> for ADS. On my side I run servers with 3 or 4 SocketAcceptors for
> different protocols, somthing like 10 SocketConnectors for different
> protocols.
> Perfs aren't an issue for me actually, be it can change.
>
>
>> - codec
>> * we don't have stateful or stateless codecs. We should distinguish
>> the two kinds of codec someone can use.
>>
> +1
>
>
>> * we should efine a collection of existing codecs
>>
> For that we need a standard way of doing a codec on the Pojo side.
> I'm sure LDAP pjo oof ADs are very different (and got different
> dependencies) of the one of Asyncweb or Vysper.
>
>
>> * as we can handle more than one protocol, we must add a
>> demuxingCodec which point to the next filter, conditionally
>>
>
> Here the graph ? :)
>
>
>> - Buffer
>> * We should not wrap ByteBuffer into our own IoBuffer class. We
>> should have a list of ByteBuffers instead, containing all the
>> ByteBuffers.
>>
> And some extended Stream interface for manipulation.
>
>> - General
>> * offer a NIO 2.0 library
>>
>>
> Well it's going to be soon mandatory :)
>
>
>> This is just a starting point ... Feel free to comment, add or remove
>> some items !
>>
>>
>
> We need at first a great test platform for testing the different
> protocols and implementation ideas (Thread/Selector/Channel
> strategies). So we make choice based on facts for the engine.
>
> Julien
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [MINA 3.0] Preliminary thoughts.
Posted by Julien Vermillard <jv...@archean.fr>.
Hi,
reply inline
Le Wed, 10 Jun 2009 21:37:10 +0200,
Emmanuel Lecharny <el...@apache.org> a écrit :
> Hi guys,
>
> as I'm commuting every day for a long distance, I have had time to
> think about what I would see in MINA 3.0. Here is the result of my
> random thoughts....
And not see anymore ;)
>
>
> Mina 3.0 design and expected features
> -------------------------------------
>
> - selectors usage
> We should be able to define the number of selectors to use, and to
> define what they will be used for. For instance, atm, we have a
> selector in the Acceptor, plus a selector per Processor. This is not
> necessarily the best solution.
>
> * do some perf tests to see if it's better to use one or many
> selectors.
> * decouple the selector usage from the the selector definition. It
> should be possible to define one single selector and use it in many
> places
> * the Acceptor and Processor should not necessarily be associated
> with a thread. it's up to the user to define the thread model to use
Actually look like we need different strategy for different usage.
On the right threading/selector strategy look like there is no real
consensus and we will need to experiment for finding the default
solution.
> - Chain
> The current chain implemention is cumbersome. We would like to have
> something easier to manipluate, and also easier to debug.
>
> * the chain should be optionally dynamic : a session can add a new
> filter in the chain whenever needed
> * we should not always copy the chain in each session, if the chain
> is immutable
Yes, cause most of time we configure the chain on the acceptor and
never change it again.
Look like we agreed on copy-on-write for that.
> * however, it should be possible to change the global chain without
> breaking the processing.
> * we should have one chain for incoming messages, and another one for
> outgoing messages
> * it should be possible to have a multi-stage codec (ie, add more
> than one codec filter in the chain)
Mandatory, it's very often I use a TextLineCodec and a String-to-Pojo
filter, and I'm sure I'm not alone.
> * we should allow a queuing mechanism to be put in between each
> filters
What is that for ? Look like you got a new idea :)
> * the Head and Tail filters are useless : they should be removed
Yes
> * a chain may not be a list of filters. It can be a graph
If we can keep the API simple enough, why not.
> - Filters
>
> * a filter should accept a stream<Object>, the Object can change from
> one filter to another. it's up to the user to correctly handle the
> Object.
You want to say multi layer codec ?
> * the executor filter could be present in moe than one place in the
> chain (SEDA)
Mandatory if someone really want SEDA.
> * statistic must be established with a filter
Again mandatory.
You won't do stats the same way on HTTP or FTP and stats can be very
costy.
> * we should define two interfaces for filters : IngoingFilter and
> OutgoingFilter. They will expose the methods to process ingoing and
> outgoing messages
The question is where to put sessionOpen/Closed/Idle in a two chains
model.
>
> - Session
> * we should have two kind of sessions : statefull and stateless.
> Sometime, we don't need to store any kind of information in a session
If we create the HashMap on first additon, where is the gain ?
> * we should add a sessionManager instead of all the existing queues
> used to manage the dead sessions, the idle sessions, etc.
We need to rethink the whole separation between IoProcessor and
IoService and where we manage closing/accepting queues.
> * session should not necessarily be associated with a processor.
+1
> * If a session is statefull, then we should attach the data to the
> channel instead of creating a map for that
Can you say more about that, where is the gain ?
> * A session must be attached to an acceptor, allowing more than one
> chain if the acceptor is to deal with more than one single
> SocketServer
We need to find away for running more than 1 kind of port/protocol with
the same set of Thread/Executors. I suppose it would be interesting
for ADS. On my side I run servers with 3 or 4 SocketAcceptors for
different protocols, somthing like 10 SocketConnectors for different
protocols.
Perfs aren't an issue for me actually, be it can change.
>
> - codec
> * we don't have stateful or stateless codecs. We should distinguish
> the two kinds of codec someone can use.
+1
> * we should efine a collection of existing codecs
For that we need a standard way of doing a codec on the Pojo side.
I'm sure LDAP pjo oof ADs are very different (and got different
dependencies) of the one of Asyncweb or Vysper.
> * as we can handle more than one protocol, we must add a
> demuxingCodec which point to the next filter, conditionally
Here the graph ? :)
>
> - Buffer
> * We should not wrap ByteBuffer into our own IoBuffer class. We
> should have a list of ByteBuffers instead, containing all the
> ByteBuffers.
And some extended Stream interface for manipulation.
>
> - General
> * offer a NIO 2.0 library
>
Well it's going to be soon mandatory :)
>
> This is just a starting point ... Feel free to comment, add or remove
> some items !
>
We need at first a great test platform for testing the different
protocols and implementation ideas (Thread/Selector/Channel
strategies). So we make choice based on facts for the engine.
Julien