directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [seda] A preview on redesigned SEDA (or Netty?)
Date Wed, 08 Dec 2004 21:31:11 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.

> 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.

Yeah we could do that but the way this would be done would be very 
specific to the nature of the protocol server.  Some servers I'm sure 
would be very conducive to it.  We could write a really generalized 
framework for that but one exists in commons called commons pipeline for 
managing logical stages.   However by sticking to handling the network 
plumbing aspects and creating a demarcation at the point of the 
ProtocolProvider allows the SEDA framework to keep its focus wrt 
networking aspects of the server.  This makes for a better framework.  
The more general a framework gets the less useful it usually becomes IMHO.

> 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.

That's cool let use know where you're doing this.

> 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).  

With the present SEDA implementation you can use the stages to build 
your own pipeline within the ProtoPro easily and that's up to u.  With 
the common plumbing of several inet servers having an input, decode, 
process, encode and output stage we took the liberty of hard coding this 
outter pipeline.   Nest into it below the ProtoPro as you like.

> Would you need to build a sort of sub-pipeline within the protocol 
> handler to accomplish this?

Just as I was describing above.  You can do this with the SEDA platform 
I have been using in the trunk.  I would imagine we could do the same if 
not better with the SEDA implementation Berin is working on.

> 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.

Yep that's my primary concern with any API and the heart of the 
framework.  Basically you have the common plumbing in place 
(input,decode,process,encode,output).  Using the same stage component 
for the stages in this prefab pipeline you should be able to build your 
own pipelines inside the ProtoPro.

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

Both Trustin and Berin have some great ideas in addition to the SEDA 
framework we have in the trunk.


View raw message