commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [chain] Pipeline implementation
Date Tue, 21 Sep 2004 21:40:19 GMT
Hi all,

Just wanted at least once to attempt to cross pollinate both lists
(Directory) and Commons by posting to both this response.  I think there
are some very interesting ideas here.  
Most likely we are not going to be able to make the SEDA stuff this
general purpose - nor do we want to however the patterns used and
problems in both spaces seem to overlap a little.

It's good to share ideas on how different people in different spaces
solve very similar problems.  The entire trail has merit and can be
accessed here in eyebrowse:

Kris my response to you is inline.

On Mon, 2004-09-20 at 13:37, Kris Nuttycombe wrote:
> Alex Karasulu wrote:
> >Hi Kris,
> >
> >On Fri, 2004-09-17 at 19:29, Kris Nuttycombe wrote:
> >
> ><snip/>
> >  
> >
> >>How is routing handled if you have multiple subscribers registered that 
> >>can handle the same type of event? 
> >>    
> >>
> >
> >The event is delivered to all subscribers then.
> >  
> >
> >>Is it possible under your framework 
> >>to explicitly specify the notification sequence such that an event is 
> >>handled by one subscriber which raises the same variety of event to be 
> >>handled by the next subscriber?
> >>    
> >>
> >
> >I think we're currently exploring things like that.  Actually this is a
> >pretty good idea in some respects to achieve something we have been
> >searching for.  Thanks for the idea I need to lull it over a bit.
> >  
> >
> Perhaps in the subscriber registration process one could pass a flag 
> that dictates whether processing of the event should be in parallel or 
> serialized? It could even be something as simple as an index where 

Funny you mentioned this.  A fellow named Trustin and I have been
discussing these same tactics just last week.

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

> >You still don't need to give up on type safety with this pub/sub model
> >because type safety is honored in the event types and the subscribers. 
> >But you still have dynamism.
> >  
> >
> The StageHandler still needs to do a runtime cast to get a useful event 
> class in any case, so I don't see how this really gives you any more 
> type safety, and you give up some modularity. If I have six different 
> types of geometry processers that need to run serially, it doesn't make 
> sense to have each of them generate a different event type because the 
> order in which these stages should be run may vary from dataset to 
> dataset. I guess I could work around this by having each stage generate 
> a unique event and changing the subscription arrangements in each case, 

We also discussed something similar.  We're still exploring the best
route to take.  What we have is definately not set in stone.

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

> >RE: the synchronization constructs needed for sequential processing
> >through portions of the pipeline we are in the process of thinking about
> >how we can do this without a lot of synch overhead.  Perhaps we can
> >think about this one together.
> >  
> >
> >>Doesn't this cause problems if your StageHandler raises the same variety 
> >>of event that caused it to be invoked in the first place?
> >>    
> >>
> >
> >If there is not terminating condition yes I would suppose so however
> >none of our stages generate the same event they process.  If they did
> >this could produce an infinate event processing loop.
> >  
> >
> 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 this is why we have started to write some simple protocols to
test the SEDA framework and see which techniques best suite our use


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message