Alex Karasulu wrote:
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.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?
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.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?
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 [EMAIL PROTECTED] =====================================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
