Re: Observing state and changes

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.

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.

Ingar



2015-06-11 13:50 GMT+02:00 Francois Daoust <fd@w3.org>:

> On 2015-06-11 12:39, Ingar Mæhlum Arntzen wrote:
>
>> Hi. Francois
>>
>> I agree about the concern that this breaks convention. I don't think it
>> violates any code practices though. As long as the user agent triggers
>> that initial event by using the event queue - registering a handler will
>> not have any (synchronous) side effects. When you register a handler you
>> must always expect that it may fire an event asynchronously at any time,
>> so event emitted 0.1 second afterwards should not be more surprising
>> than say 4.2 seconds afterwards.
>>
>
> Indeed, an event handler will be more than happy to receive the event
> regardless of when it is fired but, to be clear, the side effect I'm
> referring to is rather on the implementation side: from what I gathered in
> similar discussions in other groups, 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. This is where Dom would start arguing about trees that
> fall in a forest [1].
>
> I do not know whether there is a particular good technical reason why this
> should not or cannot be done. I do not know either if "replaying the last
> event" could be seen as different from "creating a new event".
>
> Thanks,
> Francois.
>
>
> [1] http://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest
>