Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-ID: <3C5E986F.9040100@apache.org>
Date: Mon, 04 Feb 2002 09:19:27 -0500
From: Berin Loritsch <bloritsch@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.7) Gecko/20011221
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
Subject: Re: Silk == More Seda Extractions
References: <3C59B627.7020105@apache.org>
 <200202021057.g12AvoE31135@mail016.syd.optusnet.com.au>
 <3C5D8B99.4070804@apache.org>
 <200202040925.g149Pw428385@mail012.syd.optusnet.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Peter Donald wrote:

> On Mon, 4 Feb 2002 06:12, Berin Loritsch wrote:
> 
>>>>The general concept is that a Stage consists of the Component itself
>>>>(handles the logic of the stage),
>>>>
>>>runaway! runaway! runaway!
>>>
>>>Can't we use delegation instead ? ;)
>>>
>>What are you talking about?  A Stage is a Component in the SEDA
>>architecture.
>>
> 
> You suggested that the Stage ISA EventHandler.  Haven't looked at the code 
> but thats not how I would design it. I would have the Stage contain a 
> reference to the EventHandler. I tend to prefer BlackBox frameworks over 
> whitebox ones and thus try to avoid extension via subclassing.


It is not so much subclassing, but a bunch of implemenations of the Stage interface.
Just like there are more than one instance of ConnectionManager, there is more than
one instance of Stage.  A stage is black box in the fact that the particular
Stage (EventHandler) manages what it will do with the events given to it.  The Stage
is a black box in that its processing is done in one stage, and it forwards events to
the next stage.  It is not in control of what Stage feeds it, or what stage it feeds.
That is the responsibility of the application assembler.  It also does provide for
a cleaner method of reorganizing the processing of a system that are very similar
to UNIX pipes.


>>>>My connundrum is trying to come up with a way to cleanly tie an
>>>>EventHandler to a Stage.  Should the stage implement EventHandler, should
>>>>the configuration file manage the class to be invoked, or should there be
>>>>a getHandler() method?
>>>>
>>>How about another interface "EventHandlerFactory" that is responsible for
>>>creating event handlers or something ? That way any strategy could easily
>>>be implemented by implementing a different EventHandlerFactory object.
>>>
>>No.  That is not it.  A Stage in essence *is* an EventHandler.  I would
>>prefer for stages to remain ThreadSafe, the current design allows for
>>this, and the "EventHandlerFactory" is too much overhead for not enough
>>problem.  My issue is reconciling the Block Concept to the Stage
>>concept.  All Stages have the same interface, which allows the
>>processing to be done incrementally.  Blocks have discrete interfaces,
>>which represent specific units of work.
>>
> 
> I understood what you were saying and still think what I was saying holds 
> ;)


After reaxamining the code, the EventHandler is not reused, it is the implementation
of the Stage.  The StageWrapper and Stage classes that sandStorm has are merely
management classes, and have little to do with the actual processing.  I believe that
if we have a Staged architecture, we should have clean units of reuse named Stage.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>