directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [mina] I'm adding some documentation.
Date Mon, 27 Dec 2004 17:13:49 GMT
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 <trustin@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/
>>
>>    
>>
>
>  
>


Mime
View raw message