-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Returns DataView instead of ArrayBuffer on readValue #172
Comments
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. |
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? |
It's definitely possible that some characteristics will be easier to use as a I don't have data on this, but I expect the balance of convenience points toward returning |
OK. If you want to return DataView then I think it's fine. |
Thanks! |
@beaufortfrancois happy ;) |
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. |
It'll be mailed today. |
This makes it easier to access most Bluetooth values, since they encode little-endian values of different sizes, rather than a uniform sequence of platform-endian values.
Fix #172: Return DataViews instead of ArrayBuffers.
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 |
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? |
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! |
|
OK, no problem |
I've realized that all the
arrayBuffer
I receive fromreadValue
are always wrapped around aDataView
and I was wondering if we could simply return aDataView
instead of anArrayBuffer
then.Instead of
We would have something simpler like
The text was updated successfully, but these errors were encountered: