W3C home > Mailing lists > Public > public-webtiming@w3.org > June 2015

Re: Observing state and changes

From: Francois Daoust <fd@w3.org>
Date: Thu, 11 Jun 2015 15:58:40 +0200
Message-ID: <55799410.8000100@w3.org>
To: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
CC: public-webtiming@w3.org
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:25:14 UTC