- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 30 Sep 2014 13:11:00 +0200
- To: Jeffrey Yasskin <jyasskin@google.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Marcos Caceres <marcos@marcosc.com>, public-script-coord <public-script-coord@w3.org>
On Tue, Sep 30, 2014 at 3:40 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> Does your advice also mean that the bluetooth system as a whole should
> be a class too, instead of a navigator.bluetooth that comes out of
> nowhere? But what would it mean to write `new BluetoothAdapter()`? You
> can't construct a new Bluetooth radio in software. You could imagine
> having it ask the browser to emulate a new device, but most existing
> hardware can't even emulate a new device for each origin, let alone
> multiple devices for each origin.
Yeah I'm not sure. I guess my general advice might not be applicable
here. http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/thread.html#msg213
has a discussion on sensor APIs. Perhaps some of those ideas are
applicable to Bluetooth.
> I don't understand what that means. We have some root object, either:
> 1) root_object = AClass;
> 2) root_object = navigator.foo;
> 3) root_object = new AClass();
> and then that object can expose constants as either attributes or as
> the result of methods: root_object.a_constant or
> root_object.get('a_constant').
>
> https://www.khronos.org/registry/webgl/specs/1.0/#WebGLRenderingContext
> does this as attributes (although with the discouraged WebIDL const
> keyword), while Marcos is suggesting we imitate Map's methods.
For constants the platform typically uses strings these days. See e.g.
XMLHttpRequest's responseType or JavaScript's
String.prototype.normalize().
--
https://annevankesteren.nl/
Received on Tuesday, 30 September 2014 11:11:28 UTC