- From: Francois Daoust <fd@w3.org>
- Date: Thu, 11 Jun 2015 12:26:38 +0200
- To: Njaal Borch <njaal.borch@norut.no>, Dominique Hazael-Massieux <dom@w3.org>
- CC: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>, public-webtiming@w3.org
Hi Njål, On 2015-06-10 14:11, Njaal Borch wrote: > I'm a bit confused - I thought this was what we were discussing? I.e. a > provider of a service (like Shared Motions) provide you with a vital > piece of information for your app - you have to handle changes to the > service, like it becoming ready, it being altered etc. Hence, we would > like to ensure that the initial addEventListener triggers the current > state of the service (i.e. replay the last event) to avoid having > potentially complicated code to handle various special cases. See the email I just sent in response to Ingar's first reply in this thread. Right now, this idea is considered "bad" practice but one good way to have everyone view it as a good practice would be to document all these special cases to show how this could simplify the life of developers. > > The suggestion is to avoid special cases by generalizing them - the > event listener will be triggered on registration if the event has > already been emitted. Or it's just me being very confused today, > possibly due to a too low coffee intake! Hmmm, coffee. Good idea. Francois.
Received on Thursday, 11 June 2015 10:26:52 UTC