- From: Yorkie Liu via GitHub <sysbot+gh@w3.org>
- Date: Fri, 25 Oct 2019 18:43:41 +0000
- To: public-web-bluetooth-log@w3.org
> In the discussion that we had, one of the things considered was only having the `availabilitychanged` event, implementing it such that an event is guaranteed to be fired when you install a listener for it, and removing `getAvailability()`. I'd like this solution, actually the `getAvailability()` just acts as a getter for the internal available state, which is also could be served with the `availabilitychanged` event at user-land. Thus removing `getAvailability()` would be better than my initial propose that changing its returned type. > However, we decided against that because again the potential use of the API seems low, I think browser should look more like the linux kernel to define its system calls, the high level APIs could be shipped at community libraries, thus the only important to define browser APIs is to provide the abilities correctly, and leverage community for these high-level parts. > and getAvailability() is already shipping in Chrome 78. Backwards always is an important item for developers, may a deprecation warning be the only what we can do if we were to change this :( BTW, just read again about the permission API integration and the followed section "Overall Bluetooth availability", it maybe hard to get the details for WebBluetooth implementors, I also have this kind of following questions, - What's their relationship? - Should implementor check the permission before availability returned? - Should a LSM diagram show the permission & availability state flow? -- GitHub Notification of comment by yorkie Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/459#issuecomment-546467500 using your GitHub account
Received on Friday, 25 October 2019 18:43:43 UTC