Re: [web-bluetooth] Observing characteristic notifications start and stop

Been looking at this again more recently and I'll step back and provide more context. I'm trying to wrap the Web Bluetooth api to make it available in a custom language runtime compiled to WebAssembly.

In the spec it mentions that after startNotifications event handlers can be setup within the microtask checkpoint without losing messages. Unfortunately I can't make that guarantee for nodes that execute in our runtime (two nodes may run synchronously or as separate tasks based on how they are scheduled, can't predict).

So if I try and keep a thin abstraction and have startNotifications and register event listeners as separate nodes then users may miss notifications.

Best option I can think of is either always startNotifications and stopNotifications internally and don't expose that to users or make the nodes have a parameter on the event registration node and let users manage start / stop notifications while adding or removing event listeners.

What it boils down to is why does start and stop notifications exist? Is it only because it is weird for adding event listeners to perform the action of starting notifications? Is there any actual value of having those from the bluetooth device api perspective that I'm missing?

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

Received on Sunday, 14 October 2018 23:10:38 UTC