W3C home > Mailing lists > Public > public-web-bluetooth-log@w3.org > September 2018

[web-bluetooth] Representing requestData options as JSON not possible without post processing for manufacturerData and serviceData

From: Milan Raj via GitHub <sysbot+gh@w3.org>
Date: Sun, 02 Sep 2018 23:22:42 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issues.opened-356322237-1535930561-sysbot+gh@w3.org>
rajsite has just created a new issue for https://github.com/WebBluetoothCG/web-bluetooth:

== Representing requestData options as JSON not possible without post processing for manufacturerData and serviceData ==
tl;dr: It would be helpful for different embedding contexts if the requestData options (ie filters) could be completely represented as types available in JSON.

I work on a language built with asm.js / wasm that runs in the browser and am writing an interface to web bluetooth for that language.

The language I'm working with already has good facilities for creating JSON strings from language specific array and object representations. This is in contrast to robust JS object creation and tracking which is currently very labor intensive (and on the language side requires a lot of book-keeping for tracking JS object references).

I would like to use a JSON representation for creating the requestData options. My binding layer will take a JSON string for requestData options and parse it before passing to requestData.

By using just data types and structures for the requestData options that are well represented in JSON I get a lot more flexibility by avoiding JS context being needed for parsing that configuration. I just run JSON.parse and pass through to requestData. If I want a higher-level api I can implement that in the language side without needing to track with updates to the JS side as new filtering capabilities are added over time.

While I can post-process the data and for example check for manufacturerData, servicesData, and the sub dataPrefix and mask fields represented in JSON as arrays of numbers and convert them to Uint8Array representations, it would be easier if the Web Bluetooth api allowed for either representation. This is more flexible for the language users as well since I don't have to manually track new byte array represented fields over time.

Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/407 using your GitHub account
Received on Sunday, 2 September 2018 23:22:43 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 2 September 2018 23:22:44 UTC