Re: Forward of blocked observer discussion

[Sami Wagiaalla <swagiaal at redhat dot com>]

> This adds an obscure side effect to Action.CONTINUE, is inconsistent 
> with every other observer, and is redundant.   Any observer, not just 
> a blocking observer, needing to both unblock and remove itself can 
> just request its removal.  The state machine needs to then directly 
> handle that, but as npremji recently discovered, and is now working 
> on, it isn't reliable.
Agreed. It will be hard to explain to the user why Action.CONTINUE
results in observer removal, especially if it is called instruction
observer.
> Also remember, as you/I previously discussed, and similarly I sami and 
> adam discussed, the blocking and instruction observers have too much 
> functional overlap, making one redundant.
The biggest difference between Instruction and Blocking observer is that
return Action.CONTINUE results in a instruction step for one and
resuming the process for the other, not weather it removes itself or not.

Despite the obvious functionality overlap both observers are need (at
least both names are needed). It is hard to explain to a user who wants
to block a task why they have to use an observer called
InstructionObserver, and it will also be hard to explain to a user who
wants to step a task why they have to use an observer called BlockObserver.

Why not have one be a client of the other in the same way that
TasksObserver is a client of ForkObserver and CloneObserver ? Avoiding
code and test redundancy. Or maybe just add Action.STEP :D
>   BTW, Sami/Adam preferred to see the observer called something like 
> Blocking rather than Instruction as that better reflected its behavior.

Yup. We wanted to use it for blocking, we didnt have stepping in mind.