directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [seda] A preview on redesigned SEDA (or Netty?)
Date Wed, 08 Dec 2004 19:12:26 GMT
Richard Wallace wrote:

> Hey guys,
> I'd like to chime in if I might.  A network admin friend and I have 
> decided to write a mail server in Java in our spare time, just for the 
> fun of it.  I'm eager to play with using SEDA to handle the flow of 
> operations, and was hoping I could use the SEDA library in this 
> project as the basis for that.

We are talking about two basic ways of attacking the same problem.  We 
are trying to come up with something that works,
but isn't too "frameworky" if you know what I mean.

> I'm a little confused on what you guys are discussing right now, tho. 
> Most of what you seem to be talking about sounds like a pipeline with 
> a fixed number of stages in it.  The reason I say this is because of 
> the ProtocolHandler class.  It seems to me that you would also want to 
> break up the ProtocolHandler into different stages.

This is true, but the ProtocolHandler can be broken up into different 
stages without really knowing much about SEDA or MINA.

> For instance, in Matt Welsh's http server, Haboob, he had several 
> stages dealing with cache and file IO and dynamic page generation.  I 
> plan on looking to do something similar in the mail server my friend 
> and I are getting ready to write.

Yeah, but that is kind of beyond what we need.  What we need is a 
network interaction that is scalable for an LDAP server,
which is a simpler model than serving up HTTP pages.

> I'm curious how this type of ProtocolHandler would be constructed in 
> Mina and Berin's SEDA implementation (I can't wait to see more code 
> there).  Would you need to build a sort of sub-pipeline within the 
> protocol handler to accomplish this?  I think it is very important 
> that it is easy for someone to be able to plug in a new 
> ProtocolHandler and be able to take advantage of the concurrency and 
> scalability that the non-blocking IO and SEDA provide, but it should 
> also be fairly straightforward to build new pipelines.

I think the concentration for both of us is to just be able to service 
the LDAP/Eve/Kerberos implementation we have here.  Adding more complex 
pipelines is a bit beyond what we would like to address ATM.  In the 
future we would like to set up a protocol handler to set up a load 
balancer--what would work fairly well with either framework we have set up.

> Everything I've seen so far looks great.  I'm eager to try this stuff 
> out in my own project.

You might be able to start playing with MINA.  I'm not ready with the 
simplified SEDA yet.


"Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning."
                - Rich Cook

View raw message