directory-dev mailing list archives

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

>Hi.
>
>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.
>
>HDYT?
>  
>
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.

>Cheers,
>Trustin
>  
>
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.

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


Mime
View raw message