directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: [seda] How to get protocol providers to effect SEDA?
Date Sat, 27 Nov 2004 20:09:47 GMT
> We spoke about removing the event handler or adding other mechanisms for
> linking together stages like CoR.  Perhaps we want to keep the event
> router/bus for having things repond to events even though it is not used
> for in band SEDA communication.

Stream hierarchy can handle events, too.  Only its direction is
limited, so it is OK with stram hierchy model to handle
DisconnectEvent although I think we can provide a Session.close()
method which fires it like Netty2 to let users forget about the
internal events.

> Thoughts? Volunteers to implement this?

BTW, Have a look at this interface in Netty2:

http://gleamynode.net/trac/cgi-bin/trac.cgi/file/tl-netty2/tags/1.8.0/src/main/net/gleamynode/netty2/SessionListener.java

All methods has Session as a parameter and it is the only bridge
between Netty2 and user code.  Session is an abstract Socket here
although it only works for TCP/IP for now.

and look at this:

http://gleamynode.net/trac/cgi-bin/trac.cgi/file/tl-netty2/tags/1.8.0/src/main/net/gleamynode/netty2/Message.java

Message would be a codec in the viewpoint of SEDA.  it can throw
MessageParseException while reading.  IOException,
MessageParseException (or MessageEncodeException and
MessageDecodeException in SEDA?), and any other runtime exceptions are
passed to 'exceptionCaught' method.

Events are super-flexible, but do we need that much here? 
ConnectEvent/DisconnectEvent/ExceptionEvent(not yet in SEDA) are just
commons in network applications.  Why not providing separate handler
methods?

Then RequestProcessor (or SessionListener) could handle blacklists.

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Mime
View raw message