directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [seda] Another architecture proposal
Date Tue, 30 Nov 2004 15:19:34 GMT
Trustin Lee wrote:

>I thought about xxx model discussions on SEDA.  IMHO, it is getting
>somewhat academic and being the cause of the project schedule delay. 
>So I suggest you another architecture.  Please look at the attached
>activity diagram.
Hey guys btw if you feel conversations and collaboration are delaying 
the writing of code then just create a branch, knock out some code and 
show us how it rocks.  I think that will cut to the chase on too many 
'academic' conversations.  I recommend this to anyone.  I don't think we 
loose by it or by having a few different implementations so long as we 
can finalize on one that is the best.  Even better when we find a hybrid 
that is better than its parent implementations.

>I separated SEDA into two layers; I/O layer and protocol layer.  I/O
>layer does all low-level I/O.  It fills up channel read buffer and
>flushes out channel write buffer.  All you have to do is implement
>IOHandler interface that you can get from the channel read buffer and
>can put into the channel write buffer. Protocol layer is just a
>specific implementation of IOHandler which encodes and decodes byte
>stream from/into event objects.  The use of protocol layer is
>completely optional, so you can make a high-performance or low-latency
>network applications just bypassing protocol layer. Protocol layer
>provides a ProtocolHandler which is similar to IOHandler except that
>it interacts with SEDA using event objects.
Looks cool.  I especially like how control and response to low level 
events can bubble up to the protocol handler so it can respond to them 
in a protocol specific manner like exceptions.

>SEDA I/O and protocol layer will be the core of SEDA, and we can build
>Inetd-like feature (i.e. InetDB or protocol registry) of course.
So we're going to rebuild everything from the ground up?  It's ok if we 
do I'm just curious if it is the case and why.

>The advantage of this architecture is that it is really flexible. 
>There is no restriction on the use of SEDA.  Users can use I/O layer
>only, I/O and protocol layer, or I/O and protocol layer including
>inetd feature.
Hmm that's a good point.  How about ease of use?  I don't want to 
exchange either flexibility or ease of use for the other.  We need 
both.  Like I said to you on IM we need people to be able to use this 
without having to understand its architecture or the theory behind SEDA 
or ACE. 

>This architecture does not have any event routers. It just propagates
>events to the next layer.  This could resolve the problem where
>requests are informed before ConnectEvent is and where requests are
>informed after Disconnect is.  
Awesome and this lessens the amount of synchronization we need to perform.

>It is because protocol layer is the
>only place to fire events to ProtocolHandlers so that protocol layer
>can control its order much more easily.
I love it.  But I'd love to see some interfaces carved up and look at 
some of the mechanics of using these API's.  It would give me a better 
feel.  You think you can start a branch and do this so we can go over it 
once.  If we can provide input at that stage that would be great.  

>BTW, it took really long time to draw this diagram.  Enterprise
>Architect is good, but it needs more UI improvements.
Ha! guess you gave up on using DIA :-)  I liked the diagram though.

Overall I like this alot.  Let's just keep going forward; meaning go 
ahead build her.  We can test this implementation along side other 
implementations if and when others propose them.  I think this will be 
way more performant than the SEDA we have today.

> ------------------------------------------------------------------------

View raw message