commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kris Nuttycombe" <Kris.Nuttyco...@noaa.gov>
Subject Re: [chain] Pipeline implementation
Date Tue, 21 Sep 2004 23:46:33 GMT
Alex Karasulu wrote:

>>subscribers that share the same index have events processed in parallel. 
>>Also, perhaps instead of returning void StageHandler.handleEvent() could 
>>return a boolean value that flags whether or not the event is allowed to 
>>propagate to other stages with higher serial numbers.
>
>
>That's also another good idea.  This almost reminds me of rule salience
>in expert system shells.  What stage does the event have the most
>affinity for?
>  
>
I hadn't thought of things in this context, but both the stage/event 
handling pieces of the SEDA framework and the pipeline we've developed 
here do seem a lot like frameworks for building specialized expert 
systems with concurrent processing.

>>but then it seems like you have bleeding of the application logic into 
>>the configuration realm. Maybe one could modify the StageHandler 
>>interface by adding a method that allows you to query for the runtime 
>>class of the event returned to get around this problem.
>>    
>>
>
>I don't understand the "bleeding of the application logic" comment. 
>Could you clarify this some more and explain how this is removed when
>the class of the event can be queried?
>  
>
StageHandler's handleEvent() method is regularly responsible for raising 
events and pass them back to the event router, right? The problem is 
that there's nothing in the public API that makes it clear what events a 
particluar StageHandler may generate, so establishing a routing scheme 
is a manual process that involves the programmer having knowledge of the 
StageHandler's internals. In a situation where you're trying to set up a 
linear routing scheme from a configuration file, it would make more 
sense that the ordering of elements in that file would determine the 
routing. If it's possible for a configuration tool to look at a 
StageHandler and determine what events the handleEvent method has the 
potential to raise, then automatic configuration becomes much simpler. 
It might also be useful to define a method on the interface that allows 
a handler to announce what events it can handle.

>>We do things like this all the time, but I'm beginning to see how we 
>>could get around it by having a base event type that related stages all 
>>process and have each stage raise a subtype of that event. Seems a bit 
>>like going the long way around the horn for our use case, but it might 
>>add enough value to be worth it.
>>    
>>
>
>Well this way may not be the best way for you.  This is our first
>attempt using the pub/sub pattern.  Questions about subtyping verses
>other means have been discussed.  Right now we simply don't know which
>way is the best way.  
>  
>

I think that the pub/sub model definitely has the potential to be a lot 
more powerful than our current approach; it's just a matter of 
developing the interfaces to make them flexible enough to support use 
cases for both projects. I think that our use cases are different enough 
that if we can find a model that satisfies both it will be a broadly 
useful framework.

Initially Craig had suggested setting up a commons-pipeline project in 
the sandbox. I've been preparing our code (licenses, submission 
agreements, etc) to make this transition. Are you at all interested in 
refactoring out the stage, event routing, and thread handling pieces 
from the network-oriented bits of SEDA into this project? There are 
definitely parts of your code that I'd like to be able to use without 
forking them, although I'm sure you don't really want to introduce 
extraneous dependencies.

Kris

-- 
=====================================================
Kris Nuttycombe
Associate Scientist
Geospatial Data Services Group
CIRES, National Geophysical Data Center/NOAA
(303) 497-6337
Kris.Nuttycombe@noaa.gov
=====================================================



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message