Re: New observer interface for SteppingEngine

[Adam Jocksch <ajocksch at redhat dot com>]

Mike Cvet wrote:
> Adam Jocksch wrote:
> > After some discussion with Tim and Mike, it's been generally agreed 
> > that the interface for observing the stepping engine needs to be 
> > improved beyond what's offered by the default Java 
> > Observer/Observable interface.
>
> I'm still not entirely clear on the limitations here, I only caught 
> pieces of it last week - could you describe again the problems you're 
> facing?
>
> > Looking at SteppingEngine.SteppingObserver, it looks like we need the 
> > following methods:
> > - updateTaskStopped(Task)
> > - updateNotStopped()  <-- probably taking a task as a parameter? (or 
> > maybe a list of tasks)
> > - any others?
> >
> > A few aspects of the current functionality are a little unclear to me 
> > at the moment, for example when notifyStopped() should be called and 
> > not notifyTask(Task).
> The two methods notifyStopped() and notifyTask(Task) are leftovers 
> from one of the many refactorings of the class, and should be removed. 
> The class contains methods similar to what you've described - 
> notifyNotBlocked() and updateExecuted(). When performing an operation 
> which will leave the requested Task or list of Tasks in a 
> pseudo-running state, notifyNotBlocked() tells the observers not to 
> perform any operations on the running Tasks. When each of the Tasks 
> becomes re-blocked, they pass through updateExecuted, which then calls 
> notifyObservers(Task) with the newly stopped Task.
>
> If you need to find out if a particular Task or Proc is 'running' 
> (which really means "not stopped"), then isProcRunning(LinkedList 
> tasks) and isTaskRunning (Task task) are available.
>
> - Mike
The problem is that the default Java observer interface doesn't include 
much information as to the type of message received. Having a custom 
interface will not add any extra overhead and it just seems cleaner; the 
messages for tasks running and tasks stopping are completely distinct. 
One of the issues I ran into with my code is that I wasn't sure how to 
tell why the update method was being called. With a custom observer 
interface it would be practically self-documenting. It also seems a 
little strange to have to poll all the tasks that we're interested in to 
see if they're stopped whenever we receive an event via notifyNotBlocked 
when this information could probably be send along with the message.