commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [chain] Pipeline implementation
Date Wed, 22 Sep 2004 00:42:41 GMT
On Tue, 2004-09-21 at 19:46, Kris Nuttycombe wrote:
> 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.

Good characterization! I like that.

> >>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.

Thanks I see now what you have referred to.

> >>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.

Yeah we just realy need to be careful when trying to give birth to a
panecea from the start.  I'm more in the relaxed mindset thinking we can
have two frameworks and see where we can reach common ground.  I would
love to work on both.  I think we will see more convergence in some
areas and divergence in others.  As we gain more experience and
understand all possible use cases I think we can converge if we can. 

> 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? 

Sure I would also love to be involved.

> 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.

I think we can fork it the code is not all that much.  I would rather
fork and come to a point where we reconverge instead of slowing down
development because of opposing needs.  This is a new start for both
projects; there should be room to aggressively experiment or alter their
course before binding them tightly at the hip with a common shared API.

This may be a little radical in thought but I think common libs don't
appear over night they are slowly purified from tons of different use
cases.  This IMO is what makes commons so successful.  But I'm totally
ready to work on the other extreme to - I have a slight case of
schitzophrenia :).  If you have a preference I can go with it.

Cheers, 
Alex




---------------------------------------------------------------------
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