Salut,
Emmanuel Lecharny wrote:
Hi Guys, and bienvenue Jean-François !
Merci :-)
Alex Karasulu wrote:
Welcome Jeanfrancois,
On Thu, Jun 19, 2008 at 2:15 PM, Jeanfrancois Arcand
<[EMAIL PROTECTED]>
wrote:
Salut,
after weeks of delay(ss), I'm back :-) Last time we discussed possible
collaboration between the two frameworks. I've proposed the idea to my
colleagues and as expected, every body were on the defense :-) The
Sun-Apache collaboration hasn't always working really well over the last
couple of years, and I suspect this didn't helped ;-). Let's no just
discuss
that here....
No worries. Plus from my understanding you're already an Apache
committer
right? I don't really consider you a SUN employee.
We are not in the SUN-ASF bashing business, nor in any kind of XXX vs
ASF fight business. People may have an opinion, express it, but this is
not a politic. So, you are right, we won't discuss this here. Period.
<snip/>
So, one of the proposition was to merge the two projects. I don't think
that one can happens :-)
We can still collaborate without merging. No need to push too hard on
this
front. If it happens it happens.
Exactly.
<snip/>
So my little proposal is the following. I would like to learn MINA
and be
involved as an individual contributor.
Not a problem.
One thing that I would like to
explore is have MINA implemented on top of Grizzly, similar to MINA
running
on top of APR. What the MINA community will gain with that? Little
except
the feedback I will give....
That's worth while. Plus, we would see how well the API handles your
transport. Perhaps this will help us improve the API.
Nothing to add. Just makes perfect sense.
but also it will means that application that wants to use Grizzly low
level
API can combine them with MINA high level API.
Sure this is valuable. Everyone will benefit. Just the ability to swap
transports while testing peculiarities in performance and behavior of
MINA
based applications will help shed light on what issues my exist. It's
another perspective on a problem possible with a simple switch. I think
this is a great first step.
It may also bring another value : a better separation between layers, or
so to speak, a better architecture.
Maybe nobody will want to do that, but at least it will gives me a
chance
to learn MINA and comes with comments.
I think you'll be pleasantly surprised by how many MINA people would
support
this idea.
Oh damn yeah ! MINA is far from perfect, and having guys like you on the
field is just a guarantee for many of MINA users and developpers that
new ideas will be implemented faster, and also better ! Working as a
community is so much better than as individuals...
<snip/>
I will for sure gives feedback on performance, although we might
discover
than the current version of MINA is faster than Grizzly (naaa maybe
:-)).
Julien is the guy. He has setup some environment tests, and already done
some tests. We have already discussed about them, but so many things
remains to be done !
What peoples thinks?
I think this is a very positive start. I welcome you and I would
personally
lend a hand if you have any questions. Feel free to ask on the ML and/or
just lounge out with us on #mina @ freenode.
The vary same ! Plus on est de fous, plus on rit :)
In any case, I will start looking at the design, something I've refrain
myself before (maybe I should have looked, as peoples always tell me it
quite trivial to write MINA applications!)).
Oh don't worry, the documentation is improving, slowly but surly.
We have started to add the missing Javadoc, and also trying to get the
architecture more explicit. You may have a look at this wiki page, which
has been created recently, where some class diagrams have been put :
http://cwiki.apache.org/confluence/display/MINA/Class+Diagrams
OK this is quite good
It's far from perfect, and far from being finished, but I can guarantee
that they are on line with the current classes in trunk.
Well, is much better than another framework I work on :-)
Many other things should be added, and we discussed it today :
- use cases
- collaboration diagrams
- sequence diagrams,
- maybe some Petri Net diagram if we find a tool to do that
- documented samples, from the very simplistic usage, to a complete
implementation.
All of this can be done by people who don't necessarily know the in and
out of MINA. Even better, this would benefit from someone who is
agnostic, _but_ who knows what he is talking about. Reading the code
from top to bottom is always boring, and don't gives a perfect image of
the whole thing, when checking the lib from a higher level permits to
see the flaws more easily.
+1
Welcome Jean-François !
Thanks!
-- Jeanfrancois
