> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 03, 2002 11:05 AM
> To: Avalon Developer's List
> Subject: SEDA contribution from Mark Schier
>
>
> There are some things to like such as the removal of QueueElement as a
> necesity. I have removed that from the production version of Avalon,
> as well as separated the implementation of the Queues and the
> interfaces.
Thanks!~
>
> 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.
>
> An EventHandler will respond to events it knows how to handle, and
> forward
> on any events it does not know how to handle. I think that
> is the best
> way. Throwing an exception means that the bad elements have to be
> handled
> by the container by either removing them, or moving them
> forward through
> the system. It is not the proper exception handling process for an
> event
> based system.
Right!
>
> 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.
>
> 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...
Marc
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
