Re: [web-bluetooth] Don't fire characteristicvaluechanged for Read Responses

@Emill, have you come up with a concrete use case where you need to 
distinguish notifications from read responses? I still think that 
adding a field to an event is something we can easily do even after 
everyone's implemented the spec without it.

Re changing the order of "fire an event" and "resolve promise", ["fire
 an event"]( is 
synchronous, while "resolve promise" is first observable at the next 
microtask checkpoint, so writing them in the opposite order in the 
spec would result in the same sequence of user-visible actions (except
 for further promises resolved in the event handlers). We could queue 
a task to fire the event, but that risks things getting further out of
 order, and is different from how most events are fired on the web 

GitHub Notification of comment by jyasskin
Please view or discuss this issue at
 using your GitHub account

Received on Friday, 3 February 2017 17:13:33 UTC