directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [SEDA] Some questions and idea about current SEDA API design
Date Fri, 10 Sep 2004 18:09:15 GMT

Sorry for not responding immediately I have limited connectivity now that I'm back in FL.

> From: Trustin Lee <>
> Date: 2004/09/08 Wed AM 11:12:32 EDT
> Subject: [SEDA] Some questions and idea about current SEDA API design
> I'm reading the whole source code of SEDA, and I found something unfamiliar.
> 1. Why is only one monitor per Subscriber allowed?  Is there any
> reason for this? Or, is there any reason for not using standard
> JavaBeans event model?

Ok I figure you know what this monitor business is all about by now and have looked at the
wiki here at some point:

Now you're probably think this is an event model even though callbacks are used as the hooks.
 This is something I thought at some point too and think why not have it so multiple monitors
(listeners) can be registered for events right?  

The Monitor concept is kept really simple as a simple hook: there's basically one monitor
and its a synchronous call.  More than one monitor like listeners is not used and event deliver
does not occur in another thread.  I purposefully stuck to this extremely trivial approach
because my goal was not to write an involved monitoring framework.  I merely want enough of
a hook there to avoid dependencies on logging API's where a logging monitor was needed.  Plus
I figured if there arises a need to do anything more sophisticated it can be done using another
monitor implementation.  For example I can have a monitor that allows for multiple subscribers
and delivers events to them asynchronously.  

If I had designed service interfaces to take multiple monitors as listeners then I would need
to have addMonitor, removeMonitor and would have tied implementors of the services to having
to implement these.  Plus we're trying to avoid overheads by using method callbacks instead
of event objects to encapsulate the message.  I wanted it as simple as possible while still
allowing more via monitor implementations.  WDYT?

> 2. There are so many exception handler methods in monitor interfaces. 
> I think we can replace them with single handler method
> 'exceptionCaught' and use 'instanceof' keyword against several
> exceptions to handle them case-by-case.  It will be O.K because
> there's only a few exceptions we have to handle, and logging the
> exception or closing the connection works for most of the other cases.

Ok if this is what you want to do then go for it.  You can always consolidate these if you
like so long as you get the expressivity you need to report problems or handle events (not
only exceptional ones).

> 3. How about using 'onEvent' or something sounds passive rather than
> the method name 'inform'?

Ok now we're talking about the event router (pub/sub) service.  To tell you the truth I did
not give this name to the Subscribers method.  Before starting my work on the event router/hub
I researched the various permutations of the pub/sub pattern.  Here's the exact paper I got
this from:

Even though they use 'inform' as the identifier for the delivery we don't have to stick with
it.  If you would like to go to using onEvent() give us a good argument for it and we'll switch
immediately.  Basically right now I'm piggy backing on this document as documentation for
this component and so sticking with the same method name helps.  However I'm definately ready
to change this if you elaborate further.

> 4. Isn't there any default ThreadPool implementation?

Yep there are several.  That's why we don't implement one.  If we're going to build wrappers
for this stuff to integrate into other app servers and frameworks we should presume they already
have an implementation and most likely don't want us to introduce yet another one.  Hence
our wrappers will simply **adapter** their ThreadPool class or interface using our own interface.
 This is why we do not have to have one.  Does that make sense or does this make you feel
like "well I want to run this thing now standalone and need a ThreadPool impl of some sort"?

> 5. IMHO, SEDA could be separated with multi-layered thread pool for
> generic event handling and its networking frontend (e.g. seda-event
> and seda-networking). How do you think?

Sure I agree.  This is definately somewhere we want to go as an end state.  However I want
to stage our approach towards this end.  Basically let's just get this rigged together with
TCP and UDP based protocols along with a few framework wrappers.  Let's make sure it works,
is efficient, and is very intuitive for users.  This helps us build more community around

Initially if we keep it all together it may be simpler for users to comprehend at a single
glance too.  It's more integrated and coupled yes but its all there in one place and associations
are easily made by users of the framework who just want to focus on their protocol and not
plumbing or IO.  As designers of a framework we must think as our users do.  If I put the
user cap on for a moment I want to see are really easy to use coherent framework where I do
not have to consult several packages to get the big picture in 30 seconds or less. 
As a user I got a protocol with specific protocol messages and encodings.  I want to work
at a high level receiving requests and producing responses to them while decoupling encoding
concerns which may be reused across protocols.

Now I do agree we can separate things while still keeping things simple for the users.  But
we can do the separation in refactoring cycles.  Starting separated from the onset may make
us loose track of keeping things simple for our end user.  When I looked at Coconut (a mighty
fine API btw) for example I got a bit confused and it was a bit difficult to keep track. 
I think in the end state our code will have the same separations that are naturally found
in Coconut but I think we have a better shot getting there when we work top down.  However
this obviously is an opinion on my part so the more we get the better.

Anyone else have some thoughts regarding the approach to take?


View raw message