On Tue, 3 Feb 1998, Richard Houldsworth wrote:
> 1. When exactly is the context change said to occur? I assume it
> is the point after destruction of a group and before preparation
> of another group. However, I can't find a definition anywhere.
> Perhaps a new entry in section 3, Terms and Definitions?
Good point. Can you provide us with some text?
> 2. Why do asynchronous events after the context change get cleared
> after the elementary action, and not those before? This makes the
> MHEG event handling more complex, and I can't see what good it does.
> Wouldn't simply flushing the event queue be simpler and more
> predictable?
I do not quite understand your point. The events are must be cleared
after the context change (the execution of the action) because the
action might fail and then the old scene is still valid.
> 3. By section 53.3 para 4, synchronous events generated in the
> destruction phase of context changing operations are not processed
> until after the new group has been activated. This means that
> IsStopped and IsDeleted events can never trigger links in their
> own scene (all links are deactivated by this point), but they might
Right.
> inadvertantly trigger links in the target scene for completely
> different objects.
Some might, but the "IsStopped" events don't because the targets are not
valid anymore (with the exception that you have a general Link object
which triggers on every "IsStopped" event...).
> This seems broken to me. Wouldn't it be better to
> process any pending synchronous events before preparation of the
> new group?
Hmmm, I don't know. The problem is that this is now the behaviour and
changing this might have great impact on existing applications.
> 4. What use is the IsDeleted event? I can see IsStopped being used
> for Presentables and Links that are deactivated during a scene,
> but IsDeleted only occurs on destruction (i.e. at a context change),
> when Links will not be fired (see above).
You can use it for a general "IsDeleted" Link in an Application object.
Or, you can target "Unload" to an Ingredient, this would cause the execution
of the "Destruction" behaviour and raising of an "IsDeleted" event.
> 5. We could avoid some of these problems by establishing action lists
> at synchronous event *generation* not at processing. I mean that the
> Links to fire on a synchronous event are evaluated as the event occurs.
> Links that would be deactivated during the action would still be
> fired. This is probably a common implementation optimisation anyway,
> as it removes the need for a short-lived synchronous event queue, but
> it seems to contradict 53.3 paragraph 4.
As I mentioned above, changing the event mechanism is a major change to
the standard. We should avoid this.
Regards,
Andreas
-- o _ Andreas Kraft (\_|_) GMD FOKUS, kraft@fokus.gmd.de, +49 30 3463-7232 T> ] [ The sky is the limit