You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Edouard De Oliveira <do...@yahoo.fr> on 2008/08/27 01:38:40 UTC
Re : 2.0 Roadmap ?
Hi guys,
Little late on the subject
but better late than never as people says
Code features :
>- integrating proxy patch
The proxy connector needs some javadocing and maybe some tighter integration with the core as it was
primarily intended to work out of the box without any core modifications. Some comments from the team
would be much appreciated as sometimes it is difficult to question myself after so much time thinking on it
fresh eyes could open fresh perspectives.
>- composite buffers and streams based on it
There seems to be much interest on this feature avoiding buffer copy is definitely a must have
+1
>- killing IoBuffer
Need some pointers on this discussion about the downsides of it.
>- fixing logging filter
I like Julien's hardcoded way because log filter is a debugging tool (maybe we should rename it to DebugFilter as well)
but i would add some booleans to enable/disable event logging programatically on a method basis
to make it fully configurable.
>removing netty2 codec module (who want to use it for Mina 2.0 ?)
- who is using it ? is there any advantage which is not already built-in core ? if so should we port it ?
>test coverage (yeah painfull at this point)
+1
>write traffic throttling
+1 this is tricky and providing as much help on this subject will help community
>Doc feature :
+1 to the whole doc effort
>state of the art release tarballs
Rpms and stuff is not a priority for the 2.0 release in my own opinion too.
Need to look closely to the tarballs to make structure improvements suggestions
> new website, clearer, and with better integration/links to
> subprojects like ftpserver and asyncweb
Pretty simple example it's hard to find the svn repository link so it's not really a whole start over
that is needed but maybe a clearer navigation
Hope this helps.
Cordialement, Regards,
-Edouard De Oliveira-
http://tedorg.free.fr/en/main.php
----- Message d'origine ----
De : Emmanuel Lecharny <el...@gmail.com>
À : dev@mina.apache.org
Envoyé le : Mardi, 26 Août 2008, 10h55mn 15s
Objet : Re: 2.0 Roadmap ?
Hi guys,
sorry for not having replied to this mail yesturday, I was busy with
personal stuff.
Thanks Julien for having done this summarize. I have to add that we
didn't discussed all of the items on the list with Julien, but this is a
very good thing that Julien added the important items. We badly need a
roadmap for 2.0, taht's for sure.
Comments in line
Julien Vermillard wrote:
> Hi,
>
> next step is to create a wiki page due to the size of the list :)
>
Certainly.
>
>> <snip/>
>>> Code features :
>>>
>>> - integrating proxy patch
>>>
>> Don't know what this is about.
>>
> https://issues.apache.org/jira/browse/DIRMINA-415
>
> Edouard big patch for supporting proxy such as simple port forwarding
> and SOCKS.
> It's somewhat a big patch to shallow.
>
ok. We have to look it closely.
>
>>
>>> - composite buffers and streams based on it
>>>
>> I definitely want to get involved here but I need to catch up on the
>> conversations had in the past about it.
>>
We need to discuss this item on the ML, as it will imply a hell lot of
modifications.
>>
>>
>>> - killing IoBuffer
>>>
>> +1
>>
Sure, +1.
>>
>>> - fixing logging filter
>>>
>> +1
>>
I will create a JIRA plus submit at least two proposals (code)
>>
>>> - removing netty2 codec module (who want to use it for Mina 2.0 ?)
>>>
>> +1
>>
+1
>>
>>> - test coverage (yeah painfull at this point)
>>>
>> Yeah test coverage is important but luckily MINA is not that large.
>> Test coverage makes it easier for people to get into the code to try
>> to add features or fix a bug while knowing their changes/fixes will
>> not cause regressions or breakage in the behavior of the API. Plus
>> it's the best example code to use for how to learn to use different
>> features of MINA: I always look at test code when learning how to use
>> a new piece of OSS since the docs may not be there or may not be
>> totally up to date.
>>
>>
>
> Emmanuel said me exactly the things word for word ;)
>
We are sharing a lot with Alex, but more important, we have empowered
each other to work better : removing bad habits ("Human habits ..." :)
by learning from the other, and listening to criticisms. Here, we were
on the very same page. It's also something we have gone through as we
are not young bloods... call it experience !
>
>>> - write traffic throttling
>>>
>> Yes this is a concern of mine as well. I've been experimenting in
>> the last few days specifically with ApacheDS trying to get her to
>> behave like a lady (u know not giving everything she's got and
>> overwhelming clients). I realized we need to support the MINA
>> community by making the move to MINA 2 ASAP. Was going to do this
>> last night but was wrestling with Maven issues. We'll probably make
>> the move shortly and can supply a lot of feedback with respect to
>> this aspect.
>>
>
> I wrote a little resume here of ADS problem :
> http://cwiki.apache.org/MINA/traffic-throttling.html
>
> I don't understand why it's not doable using WriteFuture.
> Would be very kind if someone of ADS can take 5 minutes to explain me
> where I'm wrong.
>
I will try to explain the problem we have. May be I'm also missing some
points.
>
>>
>>> Doc feature :
>>> - testing and perhaps tuning APR based transport
>>>
>> +1
>>
+1
>>
>>> - doc on reqres filter
>>>
>> Have not had the pleasure of looking at this filter at all - don't
>> know what it's for.
>>
>
> it's for request/response protocols, so when you send a request you can
> listen for the response in a non blocking way.
> The whole module is doc less.
>
ok. So +1
>
>>> - finishing doc on transports (core/APR/serial)
>>>
>> +1
>>
+1
>>
>>> - overall documentation (tutorial, concepts)
>>>
>> +1
>>
We badly need tutorials. Also, a while back, we discussed about buidling
a kind of Ethereal on top of MINA. The biggest advantage of doing so
(having a protocol codec for many well know protocols) is that people
who want to learn about MINA will have real life samples on how to
implement a protocol on top of MINA. Good candidates for such codec are
obviously HTTP, FTP or LDAP (which is quite complex).
>>
>>> - new website, clearer, and with better integration/links to
>>> subprojects like ftpserver and asyncweb
>>>
>> +1
>>
+1 !
>>
>>> - state of the art release tarballs
>>>
>> +1
>>
>> I think might we have some reusable infrastructure over at Directory
>> that might help with this and things like deb, pkg, rpm installers.
>> We're not starting completely from scratch in other words.
>>
>>
>
> Well MINA is a lib, so perhaps releasing linux package is a bit extreme.
> Some of the work was already contributed, we just need to find a
> workaround for a maven assembly bug.
>
Yeah, may be not necessary to deliver a rmp/deb. Maybe interesting for
AsyncWeb or FTPServer.
>>> The discussion is open, the idea is to gather wish and ideas, reach
>>> some consensus and clear the list of issue in JIRA.
>>>
>>>
>> Personally I'm disappointed by MINA's internals and how complex it is.
>> Another committer and I were discussing this complexity on IM a while
>> back. He said, "I have not read a single project that was great that
>> did not have lucid crazy simple code. It's like what Feynman said
>> about complex subjects: you don't really understand it. Same goes
>> for code. If it's complex and obfuscated you don't understand the
>> problem domain." I whole heartedly agree and there might be a need
>> for some rearchitecting for the sake of simplification and clarity.
>>
>> This can be approached in phases with subtle refactorings of the
>> internals without impacting the API. In general this will improve:
>>
>>
>> - our ability to respond to bugs,
>> - requests for new features,
>> - increase the developer adoption rate with lucid code,
>> - have better more discrete test cases for internals,
>> - and better manage and interpret issues when internals are
>> explicit in what they are designed to do
>>
>> After realizing that I need to step up, I've started reaclimating
>> myself with the internals. I could not believe how disorderly it is:
>> I thought it was in much better shape.
>>
>
> What is amazing, it's the simplicity of the API and the complexity of
> the internals, it's sure NIO is not helping us here, but the is a lot
> of things to fix/document in core. Emmanuel raised a good example with
> LoggingFilter.
>
> The death of IoBuffer will probably be the first big simplification of
> the code base.
>
Damn yes ! IoBuffer represent itself around 15% of the code.
There is another aspect which is cumbersome and complex : the filter
chain. I personnally don't think we need to have such a complex
implementation (the chaining concept is ok). For instance, we have a
HeadFilter and a TailFilter, I don't think we need them. Plus I also
think that we should distinguish between the incoming chain and the
outgoing chain. last, not least, we may need to have more than one
chain, as events may not have the same pathways. This is something we
have to think about.
Another reason why the current implementation sucks, is taht when it
comes to debug it, it's really a PITA.
>
>> In the present state, it's
>> very hard to see people with limited time frames looking at the code
>> and understanding it in time to actually affect some change. The
>> barrier is too high but we can fix that one step at a time.
>>
>> Alex
>>
>
> Yep actually MINA contributors are all hobbyist in the number of hours
> allocated, so we need reasonable target.
>
The current community is pretty wealthy, and I'm quite please to see
that ithere is a lot of positive energy, and new blood. Also we are not
in a hurry, as we don't have to deliver MINA 2.0 in 3 months. We can
spend a few extra months in order to get a good 2.0 MINA. And I don't
want to have a 2.0 out if this is just to start working on a 3.0 which
will be almost a complete rewrite.
Thanks Julien !
> Julien
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
_____________________________________________________________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
Re: Re : 2.0 Roadmap ?
Posted by Mark Webb <el...@gmail.com>.
So how can we get paid to work MINA full time ? :)
On Wed, Aug 27, 2008 at 3:37 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi Mark,
>
> thanks for the comments !
>
> More inline
>
> Mark Webb wrote:
>>
>> I agree with everything that you all have said here. The one thing I
>> would add is about the documentation/tutorials. I look around at some
>> other projects and sometimes the documentation is better, sometimes
>> its worse. Focusing on the better projects, the documentation is
>> spot-on professional. I have been working with ActiveMQ lately and
>> the whole idea of the Enterprise Integration Patterns (EIP) is
>> fantastic.
>
> AFAIK, ctiveMQ has been heavily backed by IONA, who paid some peeps to work
> on it, as they are offering Fuse, an enterprise version of ActiveMQ. THis
> may explain the quality of ActiveMQ site.
>>
>> It shows use cases and associated documentation. I think
>> this is what we need. If you want an SMTP server do this, if you want
>> an FTP server do that. The list goes on and on.
>>
>
> Agreed.
>>
>> I think part of the problem with documentation is that the learning
>> curve on the MINA internals is steep. I have been on the project for
>> a couple years and only in the last 4-6 months can I say that I really
>> understand the entire system. This makes it tough for people to dive
>> in an help.
>>
>
> That's so true ! And the overly complexity of the code, when you think that
> it's a small code base (45 KSlocs, out of which the core is 33KSlocs) is
> killing us, specially when you have sparce doc/javadoc.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: Re : 2.0 Roadmap ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Mark,
thanks for the comments !
More inline
Mark Webb wrote:
> I agree with everything that you all have said here. The one thing I
> would add is about the documentation/tutorials. I look around at some
> other projects and sometimes the documentation is better, sometimes
> its worse. Focusing on the better projects, the documentation is
> spot-on professional. I have been working with ActiveMQ lately and
> the whole idea of the Enterprise Integration Patterns (EIP) is
> fantastic.
AFAIK, ctiveMQ has been heavily backed by IONA, who paid some peeps to
work on it, as they are offering Fuse, an enterprise version of
ActiveMQ. THis may explain the quality of ActiveMQ site.
> It shows use cases and associated documentation. I think
> this is what we need. If you want an SMTP server do this, if you want
> an FTP server do that. The list goes on and on.
>
Agreed.
> I think part of the problem with documentation is that the learning
> curve on the MINA internals is steep. I have been on the project for
> a couple years and only in the last 4-6 months can I say that I really
> understand the entire system. This makes it tough for people to dive
>
> in an help.
>
That's so true ! And the overly complexity of the code, when you think
that it's a small code base (45 KSlocs, out of which the core is
33KSlocs) is killing us, specially when you have sparce doc/javadoc.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Re : 2.0 Roadmap ?
Posted by Mark Webb <el...@gmail.com>.
I agree with everything that you all have said here. The one thing I
would add is about the documentation/tutorials. I look around at some
other projects and sometimes the documentation is better, sometimes
its worse. Focusing on the better projects, the documentation is
spot-on professional. I have been working with ActiveMQ lately and
the whole idea of the Enterprise Integration Patterns (EIP) is
fantastic. It shows use cases and associated documentation. I think
this is what we need. If you want an SMTP server do this, if you want
an FTP server do that. The list goes on and on.
I think part of the problem with documentation is that the learning
curve on the MINA internals is steep. I have been on the project for
a couple years and only in the last 4-6 months can I say that I really
understand the entire system. This makes it tough for people to dive
in an help.
...just my $.02
On Tue, Aug 26, 2008 at 7:38 PM, Edouard De Oliveira
<do...@yahoo.fr> wrote:
> Hi guys,
> Little late on the subject
> but better late than never as people says
> Code features :
>>- integrating proxy patch
> The proxy connector needs some javadocing and maybe some tighter integration with the core as it was
> primarily intended to work out of the box without any core modifications. Some comments from the team
> would be much appreciated as sometimes it is difficult to question myself after so much time thinking on it
> fresh eyes could open fresh perspectives.
>
>>- composite buffers and streams based on it
> There seems to be much interest on this feature avoiding buffer copy is definitely a must have
> +1
>
>>- killing IoBuffer
> Need some pointers on this discussion about the downsides of it.
>>- fixing logging filter
> I like Julien's hardcoded way because log filter is a debugging tool (maybe we should rename it to DebugFilter as well)
> but i would add some booleans to enable/disable event logging programatically on a method basis
> to make it fully configurable.
>
>>removing netty2 codec module (who want to use it for Mina 2.0 ?)
> - who is using it ? is there any advantage which is not already built-in core ? if so should we port it ?
>
>>test coverage (yeah painfull at this point)
> +1
>
>>write traffic throttling
> +1 this is tricky and providing as much help on this subject will help community
>
>>Doc feature :
> +1 to the whole doc effort
>
>>state of the art release tarballs
> Rpms and stuff is not a priority for the 2.0 release in my own opinion too.
> Need to look closely to the tarballs to make structure improvements suggestions
>
>> new website, clearer, and with better integration/links to
>> subprojects like ftpserver and asyncweb
> Pretty simple example it's hard to find the svn repository link so it's not really a whole start over
> that is needed but maybe a clearer navigation
> Hope this helps.
> Cordialement, Regards,
> -Edouard De Oliveira-
> http://tedorg.free.fr/en/main.php
>
>
>
> ----- Message d'origine ----
> De : Emmanuel Lecharny <el...@gmail.com>
> À : dev@mina.apache.org
> Envoyé le : Mardi, 26 Août 2008, 10h55mn 15s
> Objet : Re: 2.0 Roadmap ?
>
> Hi guys,
>
> sorry for not having replied to this mail yesturday, I was busy with
> personal stuff.
>
> Thanks Julien for having done this summarize. I have to add that we
> didn't discussed all of the items on the list with Julien, but this is a
> very good thing that Julien added the important items. We badly need a
> roadmap for 2.0, taht's for sure.
>
> Comments in line
>
> Julien Vermillard wrote:
>> Hi,
>>
>> next step is to create a wiki page due to the size of the list :)
>>
> Certainly.
>>
>>> <snip/>
>>>> Code features :
>>>>
>>>> - integrating proxy patch
>>>>
>>> Don't know what this is about.
>>>
>> https://issues.apache.org/jira/browse/DIRMINA-415
>>
>> Edouard big patch for supporting proxy such as simple port forwarding
>> and SOCKS.
>> It's somewhat a big patch to shallow.
>>
> ok. We have to look it closely.
>>
>>>
>>>> - composite buffers and streams based on it
>>>>
>>> I definitely want to get involved here but I need to catch up on the
>>> conversations had in the past about it.
>>>
> We need to discuss this item on the ML, as it will imply a hell lot of
> modifications.
>>>
>>>
>>>> - killing IoBuffer
>>>>
>>> +1
>>>
> Sure, +1.
>>>
>>>> - fixing logging filter
>>>>
>>> +1
>>>
> I will create a JIRA plus submit at least two proposals (code)
>>>
>>>> - removing netty2 codec module (who want to use it for Mina 2.0 ?)
>>>>
>>> +1
>>>
> +1
>>>
>>>> - test coverage (yeah painfull at this point)
>>>>
>>> Yeah test coverage is important but luckily MINA is not that large.
>>> Test coverage makes it easier for people to get into the code to try
>>> to add features or fix a bug while knowing their changes/fixes will
>>> not cause regressions or breakage in the behavior of the API. Plus
>>> it's the best example code to use for how to learn to use different
>>> features of MINA: I always look at test code when learning how to use
>>> a new piece of OSS since the docs may not be there or may not be
>>> totally up to date.
>>>
>>>
>>
>> Emmanuel said me exactly the things word for word ;)
>>
> We are sharing a lot with Alex, but more important, we have empowered
> each other to work better : removing bad habits ("Human habits ..." :)
> by learning from the other, and listening to criticisms. Here, we were
> on the very same page. It's also something we have gone through as we
> are not young bloods... call it experience !
>>
>>>> - write traffic throttling
>>>>
>>> Yes this is a concern of mine as well. I've been experimenting in
>>> the last few days specifically with ApacheDS trying to get her to
>>> behave like a lady (u know not giving everything she's got and
>>> overwhelming clients). I realized we need to support the MINA
>>> community by making the move to MINA 2 ASAP. Was going to do this
>>> last night but was wrestling with Maven issues. We'll probably make
>>> the move shortly and can supply a lot of feedback with respect to
>>> this aspect.
>>>
>>
>> I wrote a little resume here of ADS problem :
>> http://cwiki.apache.org/MINA/traffic-throttling.html
>>
>> I don't understand why it's not doable using WriteFuture.
>> Would be very kind if someone of ADS can take 5 minutes to explain me
>> where I'm wrong.
>>
> I will try to explain the problem we have. May be I'm also missing some
> points.
>>
>>>
>>>> Doc feature :
>>>> - testing and perhaps tuning APR based transport
>>>>
>>> +1
>>>
> +1
>>>
>>>> - doc on reqres filter
>>>>
>>> Have not had the pleasure of looking at this filter at all - don't
>>> know what it's for.
>>>
>>
>> it's for request/response protocols, so when you send a request you can
>> listen for the response in a non blocking way.
>> The whole module is doc less.
>>
> ok. So +1
>>
>>>> - finishing doc on transports (core/APR/serial)
>>>>
>>> +1
>>>
> +1
>>>
>>>> - overall documentation (tutorial, concepts)
>>>>
>>> +1
>>>
> We badly need tutorials. Also, a while back, we discussed about buidling
> a kind of Ethereal on top of MINA. The biggest advantage of doing so
> (having a protocol codec for many well know protocols) is that people
> who want to learn about MINA will have real life samples on how to
> implement a protocol on top of MINA. Good candidates for such codec are
> obviously HTTP, FTP or LDAP (which is quite complex).
>>>
>>>> - new website, clearer, and with better integration/links to
>>>> subprojects like ftpserver and asyncweb
>>>>
>>> +1
>>>
> +1 !
>>>
>>>> - state of the art release tarballs
>>>>
>>> +1
>>>
>>> I think might we have some reusable infrastructure over at Directory
>>> that might help with this and things like deb, pkg, rpm installers.
>>> We're not starting completely from scratch in other words.
>>>
>>>
>>
>> Well MINA is a lib, so perhaps releasing linux package is a bit extreme.
>> Some of the work was already contributed, we just need to find a
>> workaround for a maven assembly bug.
>>
> Yeah, may be not necessary to deliver a rmp/deb. Maybe interesting for
> AsyncWeb or FTPServer.
>>>> The discussion is open, the idea is to gather wish and ideas, reach
>>>> some consensus and clear the list of issue in JIRA.
>>>>
>>>>
>>> Personally I'm disappointed by MINA's internals and how complex it is.
>>> Another committer and I were discussing this complexity on IM a while
>>> back. He said, "I have not read a single project that was great that
>>> did not have lucid crazy simple code. It's like what Feynman said
>>> about complex subjects: you don't really understand it. Same goes
>>> for code. If it's complex and obfuscated you don't understand the
>>> problem domain." I whole heartedly agree and there might be a need
>>> for some rearchitecting for the sake of simplification and clarity.
>>>
>>> This can be approached in phases with subtle refactorings of the
>>> internals without impacting the API. In general this will improve:
>>>
>>>
>>> - our ability to respond to bugs,
>>> - requests for new features,
>>> - increase the developer adoption rate with lucid code,
>>> - have better more discrete test cases for internals,
>>> - and better manage and interpret issues when internals are
>>> explicit in what they are designed to do
>>>
>>> After realizing that I need to step up, I've started reaclimating
>>> myself with the internals. I could not believe how disorderly it is:
>>> I thought it was in much better shape.
>>>
>>
>> What is amazing, it's the simplicity of the API and the complexity of
>> the internals, it's sure NIO is not helping us here, but the is a lot
>> of things to fix/document in core. Emmanuel raised a good example with
>> LoggingFilter.
>>
>> The death of IoBuffer will probably be the first big simplification of
>> the code base.
>>
> Damn yes ! IoBuffer represent itself around 15% of the code.
>
> There is another aspect which is cumbersome and complex : the filter
> chain. I personnally don't think we need to have such a complex
> implementation (the chaining concept is ok). For instance, we have a
> HeadFilter and a TailFilter, I don't think we need them. Plus I also
> think that we should distinguish between the incoming chain and the
> outgoing chain. last, not least, we may need to have more than one
> chain, as events may not have the same pathways. This is something we
> have to think about.
> Another reason why the current implementation sucks, is taht when it
> comes to debug it, it's really a PITA.
>
>>
>>> In the present state, it's
>>> very hard to see people with limited time frames looking at the code
>>> and understanding it in time to actually affect some change. The
>>> barrier is too high but we can fix that one step at a time.
>>>
>>> Alex
>>>
>>
>> Yep actually MINA contributors are all hobbyist in the number of hours
>> allocated, so we need reasonable target.
>>
> The current community is pretty wealthy, and I'm quite please to see
> that ithere is a lot of positive energy, and new blood. Also we are not
> in a hurry, as we don't have to deliver MINA 2.0 in 3 months. We can
> spend a few extra months in order to get a good 2.0 MINA. And I don't
> want to have a 2.0 out if this is just to start working on a 3.0 which
> will be almost a complete rewrite.
>
> Thanks Julien !
>> Julien
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
> _____________________________________________________________________________
> Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
Re: Re : 2.0 Roadmap ?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Julien Vermillard wrote:
> On Tue, 26 Aug 2008 23:38:40 +0000 (GMT)
> Edouard De Oliveira <do...@yahoo.fr> wrote:
>
>>> - killing IoBuffer
>>>
>> Need some pointers on this discussion about the downsides of it.
>>
>
> Emmanuel can take hours about how much he hates IoBuffer, just meet
> him ;)
>
I don't hate IoBuffer, I just hate that some time and energy has been
spent to write something which already exists : ByteBuffer, and for a
very bad reason : being able to have an extensible byte buffer.
Why is this a bad idea ? Because :
- ByteBuffers have been written in a way it can't be extended (the
constructor is package protected, and can't be called), and this was
intended.
- ByteBuffers are, err, buffers : they are supposed to _temporary_ hold
a piece of data, before it is handled by the receiving part. Extending a
buffer is just a non-sense.
Sometime, it's good to stick to the semantic, and use the existing API :
http://en.wiktionary.org/wiki/buffer#Noun
1. (computing) A portion of memory
<http://en.wiktionary.org/wiki/memory> set aside to store data
<http://en.wiktionary.org/wiki/data>, often before it is sent to
an external device or as it is received from an external device.
The base idea is that you create the buffer, fill it, and send it, or
you receive the buffer, read it, and dispose it. As you always know the
size of the data you have (either you read it from a socket, and you get
a ByteBuffer already allocated, or you create a new one to receive a
byte[], and then you already know the byte[] size, so there is no need
to resize a ByetBuffer), you don't have to resize a ByteBuffer. If you
want to be able to write or read more than one ByteBuffer, NIO already
offers the ScatteringByteChannel and GatheringByteChannel for this
purpose. No need to reinvent the wheel...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Re : 2.0 Roadmap ?
Posted by Julien Vermillard <jv...@archean.fr>.
On Tue, 26 Aug 2008 23:38:40 +0000 (GMT)
Edouard De Oliveira <do...@yahoo.fr> wrote:
> Hi guys,
> Little late on the subject
> but better late than never as people says
> Code features :
> >- integrating proxy patch
> The proxy connector needs some javadocing and maybe some tighter
> integration with the core as it was primarily intended to work out of
> the box without any core modifications. Some comments from the team
> would be much appreciated as sometimes it is difficult to question
> myself after so much time thinking on it fresh eyes could open fresh
> perspectives.
What would be interesting is to use some third party java proxy
implementation for having a correct test coverage. I seen you did
already some for your decoders. Perhaps it's not existing.
>
> >- composite buffers and streams based on it
> There seems to be much interest on this feature avoiding buffer copy
> is definitely a must have +1
>
> >- killing IoBuffer
> Need some pointers on this discussion about the downsides of it.
Emmanuel can take hours about how much he hates IoBuffer, just meet
him ;)
Mainly the problem is , we use non standard ByteBuffer, with a huge
auto extend mecanism, and it's 15% of MINA code base. A compositing
buffer or any stream interface could prolly be more compact code wise
and
> >- fixing logging filter
> I like Julien's hardcoded way because log filter is a debugging tool
> (maybe we should rename it to DebugFilter as well) but i would add
> some booleans to enable/disable event logging programatically on a
> method basis to make it fully configurable.
>
> >removing netty2 codec module (who want to use it for Mina 2.0 ?)
> - who is using it ? is there any advantage which is not already
> built-in core ? if so should we port it ?
It was a historic module for helping netty2 users to migrate to MINA.
I'm sure even netty3 doesn't support netty2 codecs.
>
> >test coverage (yeah painfull at this point)
> +1
>
> >write traffic throttling
> +1 this is tricky and providing as much help on this subject will
> help community
>
> >Doc feature :
> +1 to the whole doc effort
>
> >state of the art release tarballs
> Rpms and stuff is not a priority for the 2.0 release in my own
> opinion too. Need to look closely to the tarballs to make structure
> improvements suggestions
>
> > new website, clearer, and with better integration/links to
> > subprojects like ftpserver and asyncweb
> Pretty simple example it's hard to find the svn repository link so
> it's not really a whole start over that is needed but maybe a clearer
> navigation Hope this helps.
> Cordialement, Regards,
> -Edouard De Oliveira-
> http://tedorg.free.fr/en/main.php
Feel free to make website modification if you think so, don't worry we
still can veto/revert if it sucks ;)
>
> ----- Message d'origine ----
> De : Emmanuel Lecharny <el...@gmail.com>
> À : dev@mina.apache.org
> Envoyé le : Mardi, 26 Août 2008, 10h55mn 15s
> Objet : Re: 2.0 Roadmap ?
>
> Hi guys,
>
> sorry for not having replied to this mail yesturday, I was busy with
> personal stuff.
>
> Thanks Julien for having done this summarize. I have to add that we
> didn't discussed all of the items on the list with Julien, but this
> is a very good thing that Julien added the important items. We badly
> need a roadmap for 2.0, taht's for sure.
>
> Comments in line
>
> Julien Vermillard wrote:
> > Hi,
> >
> > next step is to create a wiki page due to the size of the list :)
> >
> Certainly.
> >
> >> <snip/>
> >>> Code features :
> >>>
> >>> - integrating proxy patch
> >>>
> >> Don't know what this is about.
> >>
> > https://issues.apache.org/jira/browse/DIRMINA-415
> >
> > Edouard big patch for supporting proxy such as simple port
> > forwarding and SOCKS.
> > It's somewhat a big patch to shallow.
> >
> ok. We have to look it closely.
> >
> >>
> >>> - composite buffers and streams based on it
> >>>
> >> I definitely want to get involved here but I need to catch up on
> >> the conversations had in the past about it.
> >>
> We need to discuss this item on the ML, as it will imply a hell lot
> of modifications.
> >>
> >>
> >>> - killing IoBuffer
> >>>
> >> +1
> >>
> Sure, +1.
> >>
> >>> - fixing logging filter
> >>>
> >> +1
> >>
> I will create a JIRA plus submit at least two proposals (code)
> >>
> >>> - removing netty2 codec module (who want to use it for Mina 2.0 ?)
> >>>
> >> +1
> >>
> +1
> >>
> >>> - test coverage (yeah painfull at this point)
> >>>
> >> Yeah test coverage is important but luckily MINA is not that large.
> >> Test coverage makes it easier for people to get into the code to
> >> try to add features or fix a bug while knowing their changes/fixes
> >> will not cause regressions or breakage in the behavior of the
> >> API. Plus it's the best example code to use for how to learn to
> >> use different features of MINA: I always look at test code when
> >> learning how to use a new piece of OSS since the docs may not be
> >> there or may not be totally up to date.
> >>
> >>
> >
> > Emmanuel said me exactly the things word for word ;)
> >
> We are sharing a lot with Alex, but more important, we have empowered
> each other to work better : removing bad habits ("Human
> habits ..." :) by learning from the other, and listening to
> criticisms. Here, we were on the very same page. It's also something
> we have gone through as we are not young bloods... call it
> experience !
> >
> >>> - write traffic throttling
> >>>
> >> Yes this is a concern of mine as well. I've been experimenting in
> >> the last few days specifically with ApacheDS trying to get her to
> >> behave like a lady (u know not giving everything she's got and
> >> overwhelming clients). I realized we need to support the MINA
> >> community by making the move to MINA 2 ASAP. Was going to do this
> >> last night but was wrestling with Maven issues. We'll probably make
> >> the move shortly and can supply a lot of feedback with respect to
> >> this aspect.
> >>
> >
> > I wrote a little resume here of ADS problem :
> > http://cwiki.apache.org/MINA/traffic-throttling.html
> >
> > I don't understand why it's not doable using WriteFuture.
> > Would be very kind if someone of ADS can take 5 minutes to explain
> > me where I'm wrong.
> >
> I will try to explain the problem we have. May be I'm also missing
> some points.
> >
> >>
> >>> Doc feature :
> >>> - testing and perhaps tuning APR based transport
> >>>
> >> +1
> >>
> +1
> >>
> >>> - doc on reqres filter
> >>>
> >> Have not had the pleasure of looking at this filter at all - don't
> >> know what it's for.
> >>
> >
> > it's for request/response protocols, so when you send a request you
> > can listen for the response in a non blocking way.
> > The whole module is doc less.
> >
> ok. So +1
> >
> >>> - finishing doc on transports (core/APR/serial)
> >>>
> >> +1
> >>
> +1
> >>
> >>> - overall documentation (tutorial, concepts)
> >>>
> >> +1
> >>
> We badly need tutorials. Also, a while back, we discussed about
> buidling a kind of Ethereal on top of MINA. The biggest advantage of
> doing so (having a protocol codec for many well know protocols) is
> that people who want to learn about MINA will have real life samples
> on how to implement a protocol on top of MINA. Good candidates for
> such codec are obviously HTTP, FTP or LDAP (which is quite complex).
> >>
> >>> - new website, clearer, and with better integration/links to
> >>> subprojects like ftpserver and asyncweb
> >>>
> >> +1
> >>
> +1 !
> >>
> >>> - state of the art release tarballs
> >>>
> >> +1
> >>
> >> I think might we have some reusable infrastructure over at
> >> Directory that might help with this and things like deb, pkg, rpm
> >> installers. We're not starting completely from scratch in other
> >> words.
> >>
> >>
> >
> > Well MINA is a lib, so perhaps releasing linux package is a bit
> > extreme. Some of the work was already contributed, we just need to
> > find a workaround for a maven assembly bug.
> >
> Yeah, may be not necessary to deliver a rmp/deb. Maybe interesting
> for AsyncWeb or FTPServer.
> >>> The discussion is open, the idea is to gather wish and ideas,
> >>> reach some consensus and clear the list of issue in JIRA.
> >>>
> >>>
> >> Personally I'm disappointed by MINA's internals and how complex it
> >> is. Another committer and I were discussing this complexity on IM
> >> a while back. He said, "I have not read a single project that was
> >> great that did not have lucid crazy simple code. It's like what
> >> Feynman said about complex subjects: you don't really understand
> >> it. Same goes for code. If it's complex and obfuscated you don't
> >> understand the problem domain." I whole heartedly agree and there
> >> might be a need for some rearchitecting for the sake of
> >> simplification and clarity.
> >>
> >> This can be approached in phases with subtle refactorings of the
> >> internals without impacting the API. In general this will improve:
> >>
> >>
> >> - our ability to respond to bugs,
> >> - requests for new features,
> >> - increase the developer adoption rate with lucid code,
> >> - have better more discrete test cases for internals,
> >> - and better manage and interpret issues when internals are
> >> explicit in what they are designed to do
> >>
> >> After realizing that I need to step up, I've started reaclimating
> >> myself with the internals. I could not believe how disorderly it
> >> is: I thought it was in much better shape.
> >>
> >
> > What is amazing, it's the simplicity of the API and the complexity
> > of the internals, it's sure NIO is not helping us here, but the is
> > a lot of things to fix/document in core. Emmanuel raised a good
> > example with LoggingFilter.
> >
> > The death of IoBuffer will probably be the first big simplification
> > of the code base.
> >
> Damn yes ! IoBuffer represent itself around 15% of the code.
>
> There is another aspect which is cumbersome and complex : the filter
> chain. I personnally don't think we need to have such a complex
> implementation (the chaining concept is ok). For instance, we have a
> HeadFilter and a TailFilter, I don't think we need them. Plus I also
> think that we should distinguish between the incoming chain and the
> outgoing chain. last, not least, we may need to have more than one
> chain, as events may not have the same pathways. This is something we
> have to think about.
> Another reason why the current implementation sucks, is taht when it
> comes to debug it, it's really a PITA.
>
> >
> >> In the present state, it's
> >> very hard to see people with limited time frames looking at the
> >> code and understanding it in time to actually affect some change.
> >> The barrier is too high but we can fix that one step at a time.
> >>
> >> Alex
> >>
> >
> > Yep actually MINA contributors are all hobbyist in the number of
> > hours allocated, so we need reasonable target.
> >
> The current community is pretty wealthy, and I'm quite please to see
> that ithere is a lot of positive energy, and new blood. Also we are
> not in a hurry, as we don't have to deliver MINA 2.0 in 3 months. We
> can spend a few extra months in order to get a good 2.0 MINA. And I
> don't want to have a 2.0 out if this is just to start working on a
> 3.0 which will be almost a complete rewrite.
>
> Thanks Julien !
> > Julien
> >
>
>