directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [seda] How to get protocol providers to effect SEDA?
Date Sun, 28 Nov 2004 08:13:57 GMT
Trustin Lee wrote:

>>>Many/Single/NoReplyHandler has a handle() method which has ClientKey
>>>type parameter.  ClientKey.expire() has protected acess modifier
>>>because it directly closes the socket for now.  But this could change
>>>it to 'public' if we can fire DisconnectEvent, or it would be just OK
>>>to modifying access modifier if the usecase is blacklist only for a
>>Yeah this is a hack though as you hinted already.  Perhaps the best
>>thing to do is enable protocol providers with a handle to the event
>>router and have them capable of publishing Events.  I think this opens
>>up the gambit of possibilities - not just shuting down a connection or
>>enabling blacklists but much more.  We cannot possibly foresee all the
>>possible interactions that can occur for all protocols and the event
>>model is most excellent for this.
>That's a good idea.
>>I hope your distaste for the many problems within SEDA does not make you
>>loose faith in the usage of this pattern - it really is nice to have
>>because it allows any kind of event to be published.  If this event has
>>merit then something listens and responds to it.  This is an excellent
>>decoupled way to have the provider talk back to the system without hard
>>dependencies.  Now the in band processing of Events with the pattern is
>>not the best thing as we discussed for SEDA because of performance
>>issues with stage syncronization.  By in band I am referring to the
>>events used for actually processing requests as opposed to events for
>>setup and teardown.  Really try to give the pattern a second thought not
>>for the in band processing which is expensive and needs to change but
>>for loosly couple parts of the system that may need to communicate
>>without performance issues in the way.  Like for setup, configuration or
>>communicating things between the provider and the SEDA layer whatever
>>that may be tommorrow.
>No worries, I'm flexible.  I'll try to start from event model again. :)
No need to stick to it for everything either.  I really like the new 
stuff you were talking about too which is more ACE like.  And then there 
was the use of CoR which some people from commons spoke to me about 
regarding similarities with SEDA.  So you got some great ideas.  Just 
keep the event thing in mind that's all - if it does not meet your needs 
then it can go.


View raw message