Re: Observing state and changes

I hope someone actually can shed some light on this, as frankly, I can't
see how not creating a local event object asynchronously could be much of
an optimization on anything.  In particular as the trade off is that
complexity will rise for pretty much *all users* of stuff like Shared
Motions.

In particular, most use of timing objects likely need to handle changes to
the timing object (polling is an option, but not a very nice one).  Thus,
everyone should support asynchronous events.  Not providing the initial
event (or state) will therefore add complexity in pretty much all code
using the timing object.  Not only by doing a check, but it will also
require you to register to a "readystatechange" event to figure out when
you can query for timing state.  So instead of one simple:

myTimingObject.addEventListener("change", functon(e) { do something});

one also needs
myTimingObject.addEventListener("readystatechange", function() {
  if readystate is appropriate readyness {
    create new event;
    emit event;
  }
});

So we add code and create special cases to handling this, in pretty much
*every case*.  Now THAT has got to be an anti-pattern if ever I saw one. :-)

Just as a small digression - the track element does the same thing - you
must register to cue changes (emitted while playing over them), but you get
nothing on skips and have to manually hook up to the driving clock for
changes and process the list of active cues.  Lots of code and mental
processing to work around a very simple construct in my opinion.

N


---
Dr. Njål Borch
Senior researcher
Norut Tromsø, Norway

On 11 June 2015 at 15:58, Francois Daoust <fd@w3.org> wrote:

> 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.
>
>