Re: Observing state and changes

On 2015-06-11 15:06, Ingar Mæhlum Arntzen wrote:
> Francois
>
> "implementers do not want the action of registering an event handler to
> have the side effect of possibly creating an event, in other words to
> have any impact on the stream of events that will be generated"
>
> I think this statement must really be restricted to *synchronous*
> creation of events. I find it hard imagine that an event created
>   *asynchronously* by handler register can have unwanted side-effects,
> as from the perspective of the consumer the situation is
> indistinguishable from a situation where an extra event is created
> asynchronously for any other reason. The only issue I can see is if
> consuming software somehow depends on timestamps in the event stream,
> and the "lateness" of the replayed event is not correctly reflected.

Again, the only side effect that I hear people want to avoid is the 
creation of the event in itself, not the side-effects that this event 
might have. Perhaps someone on this list can chime in and provide the 
rationale that I do not have :)


>
> Also, we are not suggesting to silently abuse the well defined semantics
> of IEventListener, but rather to define a new event interface say
> "IStateEventListener" where this semantic is well specified.
>
> However, as this is not *critical* to the timing model - I'm reluctantly
> ok with dropping the proposal (for now) and go on with the regular
> eventing model.

This why I suggest to focus on use cases. If this constructs proves 
extremely useful to enable useful scenarios, then I think it's ok to use 
it in the spec, restricting it to certain types of events to start with, 
for instance not for readyState changes but for a possible events stream 
that would come from the online timing service.

Francois.

Received on Thursday, 11 June 2015 13:58:56 UTC