- From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2015 18:02:02 +0000
- To: public-web-bluetooth-log@w3.org
https://www.khronos.org/registry/webgl/specs/1.0/#WebGLRenderingContextBase endorses both ALL_CAPS attributes for constants and consistency with an [external specification](https://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.25.pdf) (that itself uses ALL_CAPS), rather than a mapping function. Other than that, I don't see a [device capability API](http://www.w3.org/2009/dap/) that needs to interoperate with externally-defined constants, especially the unreadable UUID constants that Bluetooth uses. Nonetheless, for this API, just about every web platform expert I've talked to has preferred a mapping function on some `BluetoothXyz` interface, so it doesn't seem worthwhile to try to argue for anything else. For `requestDevice`, the most similar proposal is [SerialPort.requestList()](http://whatwg.github.io/serial/#serialport-interface), but several others use `navigator.Xyz()` ([navigator.vibrate()](http://www.w3.org/TR/vibration/#vibration-interface), [navigator.getBattery()](http://www.w3.org/TR/battery-status/#the-navigator-interface), [navigator.mediaDevices.enumerateDevices()](http://w3c.github.io/mediacapture-main/getusermedia.html#mediadevices) so @esprehn's advice to keep what we have seems fine. -- GitHub Notif of comment by jyasskin See https://github.com/WebBluetoothCG/web-bluetooth/issues/49#issuecomment-97899559
Received on Thursday, 30 April 2015 18:02:03 UTC