directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [seda] How to get protocol providers to effect SEDA?
Date Sun, 28 Nov 2004 06:50:06 GMT
> >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
> >while.
> >
> >
> >
> 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. :)

what we call human nature is actually human habit

View raw message