Returns DataView instead of ArrayBuffer on readValue

[beaufortfrancois]

I've realized that all the arrayBuffer I receive from readValue are always wrapped around a DataView and I was wondering if we could simply return a DataView instead of an ArrayBuffer then.

Instead of

characteristic.readValue().then(buffer => {
  let data = new DataView(buffer);
  let foo = data.getUint8(0);
  ...

We would have something simpler like

characteristic.readValue().then(data => {
  let foo = data.getUint8(0);
  // We can always access ArrayBuffer if we need to with data.buffer
  ...

[jyasskin]

https://heycam.github.io/webidl/#idl-buffer-source-types says "When designing APIs that create and return a buffer, it is recommended to use the ArrayBuffer type rather than Uint8Array." However, I agree that the DataView is more convenient for most uses of Characteristic values, since they tend to be heterogenous.

@heycam, is that bit of WebIDL intended to discourage returning DataViews too? Is this something we should bring up on public-script-coord or just change here? Thanks.

[heycam]

The suggestion there is to dissuade people from using Uint8Array as a "generic buffer of data" type, when ArrayBuffer is more appropriate for that. If you want you can provide a DataView, but is it possible that for a given characteristic it might be more convenient for the author to have a different typed array view of the buffer, and so you should leave the choice of whether to wrap the buffer in a DataView or one of the other types up to them?

[jyasskin]

It's definitely possible that some characteristics will be easier to use as a UInt8Array, in which case the author would need to write new UInt8Array(view.buffer) explicitly. Some characteristics may also store an array of 16- or 32-bit integers, but in those cases authors will need to use DataView over UInt16Array because they'll need to select the byte ordering of the remote data, rather than their platform's ordering. (Worse, most platforms are little-endian, which matches the common Bluetooth ordering, so if authors use UInt16Array, they'll get the right answers on their development machines but break on big-endian implementations ... if any of those exist.)

I don't have data on this, but I expect the balance of convenience points toward returning DataView.

[heycam]

OK. If you want to return DataView then I think it's fine.

[jyasskin]

Thanks!

[beaufortfrancois]

@beaufortfrancois happy ;)

[beaufortfrancois]

WIP at https://codereview.chromium.org/1603893002

[g-ortuno]

Could we get this in the spec first before we implement it? We don't want to introduce discrepancies between the browser and the spec specially now that other browsers are implementing.

[jyasskin]

It'll be mailed today.

[thegecko]

I'm aware this specification targets web browsers, but in situations where the specification may be implemented in different environments, using more specific data structures can make conversion and usage difficult, .e.g. node:

https://github.com/thegecko/bleat/blob/web-bluetooth/dist/bleat.noble.js

[g-ortuno]

How would returning a DataView make conversion more difficult? Converting from an ArrayBuffer to DataView is fairly easy:

var buffer = new ArrayBuffer(2);
var dataView = new DataView(buffer);

Similarly from DataView to ArrayBuffer:

var buffer = dataView.buffer;

What am I missing?

[thegecko]

OK, I spent a bit of time investigating this and node supports DataViews. If I come across other JS engines which supports ArrayBuffers but not DataViews, I'll comment here. My concern was simply that using more specific constructs in the target (web) environment could make implementing this specification in other JS environments more difficult. Thanks!

[jyasskin]

DataView is part of Javascript, so I wouldn't expect any other JS engines to support ArrayBuffer but not it. However, if you notice us depending on any part of HTML that standalone JS engines don't support, do let us know, and we'll try to work something out.

[thegecko]

OK, no problem