You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2004/12/27 08:43:51 UTC
[mina] I'm adding some documentation.
Could you review my JavaDocs although I didn't complete it yet? :) I
uploaded it at:
http://www.apache.org/~trustin/mina/
I expect I can release MINA v0.7 in January. HDYT?
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] I'm adding some documentation.
Posted by Trustin Lee <tr...@gmail.com>.
Hi Alex, how was your vacation? :)
<snip/>
> >Looking at docs you generated I
> >cannot see difference between MINA and SEDA projects (there is also
> >SEDAng on directory webpage - I'm affraid to ask about it ;-)).
> >
> Trustin, I don't think will be insulted by my saying his documentation
> lags behind his coding skills :-). I think this similarity was a result
> of a copy and paste job from the xdocs of the SEDA project and he has
> not filled in completely. I'm sure Trustin will give us profuse amounts
> of docos.
Actually I was concentrating on bringing up MINA to relesable state.
I'm adding bunch of JavaDocs and tutorials to MINA. I believe I can
finish doco before this year goes away. My aim in my heart was to
replace SEDA as soon as possible to lessen the burden of docos. Then
we could add and stablize more docos while SedaNG is finished.
<snip/>
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] I'm adding some documentation.
Posted by Michal Slocinski <ms...@gmail.com>.
On Mon, 27 Dec 2004 12:13:49 -0500, Alex Karasulu <ao...@bellsouth.net> wrote:
> Hi Michal,
>
> Great questions! I'm glad you came out and asked. Thanks!
>
I'm more than glad reading such solid reply! I'm sure some of these
words should appear on Directory project web page to prevent next
users confusions (or maybe this should be done by main MINA/SedaNG
developers). Anyway - your mail helped me a lot with understanding
what is going on in this project :-)
It would be also great to read about approaches and general ideas of
MINA/SedaNG implementations, in which situations each of them will be
better from another. I think it'll be hard to find new
developers/contributors from outside when they have to penetrate
sources to catch main ideas of each framework.
Main reason why I'm interested in SEDA/MINA/SedaNG is that I'm looking
for a really robust network application architecture that will be able
to handle big number of requests, generate same number of responses
and act as a proxy for some of requests. Protocol is RADIUS so it is
UDP based, that's why I'm asking about comparison of both approaches.
I have some free time next days so I'll try to study sources but it
would be greatly appreciated to read some words from both MINA/SedaNG
developers :-) I'll try to track also JIRA to see how far both of them
are in their roadmaps.
best regards to all Directory developers :-)
Michal
Re: [mina] I'm adding some documentation.
Posted by Alex Karasulu <ao...@bellsouth.net>.
Hi Michal,
Great questions! I'm glad you came out and asked. Thanks!
Michal Slocinski wrote:
>Hi,
>
>I'm quite new here, since this moment most everything was clear to me,
>but now - I'm little bit lost :-)
>
I appologize about this! I am begining to realize the confusion users
like yourself are having. Several others have already contacted me off
list about this matter which is also perplexing them. I hope they can
voice their opinions on list from now on.
Let me first describe the history of events leading to the present day ...
Originally there was the seda framework by itself. As you know it is a
network framework where protocols can be snapped in. It is intended for
using the same plumbing while enabling each protocol with SEDA (in caps
to denote Matt Welsh's architecture as opposed to our specific
implementation of the architecture).
For the record, the directory project is not centrally concerned with
networking frameworks. We want to implement protocols, namely directory
protocols, or protocols that leverage directories as their backing store
and have some relationship to X.500 series standards. Regardless all
these protocols will have similar needs where networking code is
concerned. It made sense in this respect to have a framework where we
can snap in multiple protocols both from a reuse perspective and a
network service colocation (in same process) perspective. Personally
I'm not the brightest bulb in the pack when it comes to this stuff. I
just got SEDA working as best as I could to have it serve as Eve's
network frontend.
As protocol implementors we want the best networking layer for all
situations. Perhaps this is a chimera/panacea we will be chasing for a
long time to come. And perhaps it can be done if the scope is limited.
There are a couple camps out there that support different architectures
for protocol servers. There are the SEDA and ACE camps. There probably
are a few more out there. It's really a waste to have people who do not
have the passion for building the next best protocol framework chasing
after this dream. Guys like Trust and Berin on the other hand are very
interested in this persuit. They have also done this before and have
the experience. Each have their own approach which is perfectly ok even
if their byproducts are not complementary.
At first I personally envited Trustin to join us here at Directory. He
had written Netty and Netty2 which are two easy to use network API's.
He came initially to help out with SEDA. Since then he fixed up SEDA
and maintains it today but he really wanted to start something different
and from scratch (my code probably scared him away :-)). I encouraged
that and made a deal with him: maintain SEDA until MINA or something
else can replace it. Sometimes you do need a clean slate and Trustin
was leaning more towards a hybrid of Netty2 and ACE principles. This
gave birth to MINA. Again I don't care what we use. I do have some
requirements though. First it must be efficient. Second it must meet
our needs for protocol server developement. Lastly and most importantly
it must have a community that takes ownership of it to support and
maintain it.
Next Berin and I started talking about some of his work for a SEDA
implementation. He was driven to implement the next best SEDA
implementation, the next generation so to speak. I encouraged this as
well and sedang for, seda the next generation was created and Berin is
actively working on this here in parallel with Trustin's MINA effort.
Trustin, and Berin (and I for that matter) can implement network
frameworks until the cows come home. IMO no framework will be worth
anything unless it is sculpted by user requirements, tested when used in
the real world by protocol servers. The mixture of people and
initiatives here at the directory project present a unique opportunity
for the evolution of the network frameworks that Trustin and Berin are
building. First the environment offers them a user base of protocol
implementors and a set of real world protocol servers. The requirements
for LDAP, Kerberos, Changepw and eventually DNS and DHCP (the secret has
been reveiled :-)) will drive the design of their frameworks. The users
of these servers will in turn become testers of their frameworks.
Different real world scenarios will be encountered to push their
limits. This is by far the most powerful evolutionary force that will
turn MINA and SedaNG into viable network frameworks. Personally I will
would like to retire the network framework developer position and focus
on Kerberos and LDAP server developement. I have trust in Trustin
(excuse the pun) to maintain SEDA so long as we still use it and until
it can eventually be retired in preference for both these frameworks
using a common API.
I would like to foster this environment because it is in our interest as
a protocol implementors. On the otherhand I would like to guide them
towards converging on a common API. This API hopefully will be the one
that protocol implementations will use to snap their protocols into
seda, sedang, and mina without code changes. You see IMO I feel that
their work is more complimentary suiting different usage scenarios where
it becomes a deployment choice. Users should be able to chose the
network architecture for their protocol server at deploy time based on
their needs without effecting the protocol implementation. This I
think is totally possible if we limit our scope to a network framework
as opposed to an end-all-be-all generic framework. The two models again
IMO complement each other fairly well. I think sedang will be better
suited for highly concurrent protocol servers based on TCP where as MINA
will be better at dealing with reponsive UDP servers and TCP servers
without a high degree of load. Again all this is conjecture! The
ultimate truth is in the metrics produced from pounding on the servers
running on theses frameworks. If the same API is used, we can even have
the same server instance bound to different ports servicing requests
through different frameworks! How crazy is that?
Ok I oppologize for the long story but I'm sure it clarifies things to
some degree and makes things clear for all of us here at the Directory
Project. Please Trustin, Berin or anyone else let me know if I was off
anywhere.
>Looking at docs you generated I
>cannot see difference between MINA and SEDA projects (there is also
>SEDAng on directory webpage - I'm affraid to ask about it ;-)).
>
Trustin, I don't think will be insulted by my saying his documentation
lags behind his coding skills :-). I think this similarity was a result
of a copy and paste job from the xdocs of the SEDA project and he has
not filled in completely. I'm sure Trustin will give us profuse amounts
of docos.
>Could
>you explain what kind of relationship exists between MINA, SEDA,
>SEDAng and Protocol subprojects of Directory?
>
>
Both eventually will support a common API used by protocol
implementors. With a common protocol API implementors will only need to
write one version of their server instead of maintaining two or more
branches of code for each newtork framework. This way users of the
server can opt to use one framework over the other based on the
characteristics of the protocol architecture supported by the
framework. In the end, we want the user to win even if it costs the
framework developer a little more effort. This is absolutely critically
IMO and the reason why we all agreed to this collaborative effort. It
is the binding contract in many respects.
>I suppose that MINA is like basic NIO framework, SEDA will bring some
>Staged-Event architecture on top of MINA, am I correct?
>
We have yet to explore these aspects. I think its early but yes you
have a good idea. SEDA can be stacked on top of MINA I think. Perhaps
this will be impractical in some respects costing the SEDA
implementation or making the MINA implementation bend over backwards. I
really don't know. I'd like to see things naturally develope. For now I
think both Trustin and Berin need room to breath and start work from
scratch. However they are working well together and collaborating to
make sure they converge on one common API. It's exciting to watch
things progress. I'm anxious for the day when we can retire the older
seda implementation for the common protocol API and have a choice
between MINA and SedaNg. Later I'd like to see some experimentation with
hybrids or stacking of frameworks as you so insightfully recommended.
>If yes, what
>kind of relationships exist between these projects and
>Protocol/SEDAng?
>
>
>
The protocol project is for the common protocol API (or is this more of
an SPI?). This is where MINA and SedaNg converge.
Cheers,
Alex
>best regards
>
>On Mon, 27 Dec 2004 16:43:51 +0900, Trustin Lee <tr...@gmail.com> wrote:
>
>
>>Could you review my JavaDocs although I didn't complete it yet? :) I
>>uploaded it at:
>>
>>http://www.apache.org/~trustin/mina/
>>
>>I expect I can release MINA v0.7 in January. HDYT?
>>
>>Cheers,
>>Trustin
>>--
>>what we call human nature is actually human habit
>>--
>>http://gleamynode.net/
>>
>>
>>
>
>
>
Re: [mina] I'm adding some documentation.
Posted by Michal Slocinski <ms...@gmail.com>.
Hi,
I'm quite new here, since this moment most everything was clear to me,
but now - I'm little bit lost :-) Looking at docs you generated I
cannot see difference between MINA and SEDA projects (there is also
SEDAng on directory webpage - I'm affraid to ask about it ;-)). Could
you explain what kind of relationship exists between MINA, SEDA,
SEDAng and Protocol subprojects of Directory?
I suppose that MINA is like basic NIO framework, SEDA will bring some
Staged-Event architecture on top of MINA, am I correct? If yes, what
kind of relationships exist between these projects and
Protocol/SEDAng?
best regards
On Mon, 27 Dec 2004 16:43:51 +0900, Trustin Lee <tr...@gmail.com> wrote:
> Could you review my JavaDocs although I didn't complete it yet? :) I
> uploaded it at:
>
> http://www.apache.org/~trustin/mina/
>
> I expect I can release MINA v0.7 in January. HDYT?
>
> Cheers,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>