> From: Marc Schier [mailto:[EMAIL PROTECTED]] > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > > However, there are some things that I am curious as to your > reasoning. > > The version of SandStorm (the SEDA implementation that inspired the > > event package) did not have EventHandlerExceptions, and I > don't think > > that they belong. > > I agree. I needed some signalling because all the exceptions > in Sandstorm are just print to stdout. I thought I would > handle an exceptional condition somewhere else.
I think the signal based system would work best. > > What should happen is the EventHandler/Stage should enqueue > a Signal > > that the container can divert to the SignalHandler. That way we > > can properly > > log the event. As it is now, we would loose information should the > > EventHandler not properly process or forward the faulty > > elements before > > it throws the exception. That IMO is a bad thing. > > I agree. Using a signal handler for logging would be a very > good way of doing it. Not to mention the fact that the signal handler would be able to do more than *just* log it. It can do proper notifications in the event that the signal represents a serious enough issue. > > Regarding the Stage Queue operations, I think we can clean > things up. > > If the Stage can get its Sink directly set by the container, we can > > set up a multiplexing queue based on the type of element. However, > > that requires > > the container to have intimate knowledge of the types that > come out of > > the Stage. I don't think the Stage should want to enqueue things to > > itself > > again. That might cause some other issues such as infinite > loops that > > are > > hard to detect. If we keep to the SinkMap format, we should keep it > > simple. > > The SinkMap would return the default Sink, and a small collection of > > named > > sinks. That way the Stage can make intelligent decisions > as to which > > Sink > > it forwards information to. > > Again, I agree, but the sandstorm stages have the notion of > enqueuing to their own sink and because I ported the whole > thing over, I wanted the stage to get a reference to its own > sink. This is very error prone and probably will lead to > really low reuse (But the current stage manager does not very > much allow reuse anyway). It could be handle by designing > smaller stages that handle one single event. I would also > like to see it go away... Did you have any talks with Matt regarding his reasoning for the self queueing stages? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
