Currently, we always convert BluetoothUuid to a string after get it from HAL. We can save the convert effort in gecko if we modify the Convert() in HAL from bt_uuid_t <-> BluetoothUuid to bt_uuid_t <-> nsString.
Hi Thomas, Based on current code base, it looks like nsString is what we need in gecko instead of a BluetoothUuid struct with a byte array. Hence, maybe it's better that we convert bt_uuid_t to a nsString directly in HALHelper. May I ask if you have any concerns about replacing BluetoothUuid struct with nsString? Thanks, Jocelyn
Hi Jocelyn, I do have concerns. I'm trying hard to separate the back-end code from the rest of Gecko and this would be a step backwards. We should keep the UUID structure internally and convert it to a string only when handing it over to Gecko's DOM. So instead of representing UUIDs as strings, it would be better to 1) replace those uint8_t arrays in Bluetooth*Interface by BluetoothUUID, and 2) make sure we use BluetoothUUID throughout Gecko. The same is true for addresses BTW. We are currently representing them as strings, but that's inefficient (UTF16 + terminal \0) and leads to all kinds of hacks in the back-end's conversion code. Representing them as fixed-size structure internally would improve the code significantly.
> 1) replace those uint8_t arrays in Bluetooth*Interface by BluetoothUUID, and > 2) make sure we use BluetoothUUID throughout Gecko. I'd be happy to review a patch for this change BTW. But I'm also worried about introducing differences between bluetooth/ and bluetooth2/.
Remove [bluetooth2] from title since it's already landed on m-c.
Summary: [bluetooth2] Follow-up to Bug 1063449: Replace BluetoothUuid as nsString → Follow-up to Bug 1063449: Replace BluetoothUuid as nsString
Resolve as WONTFIX since bug 1215525 replaced strings with |BluetoothUuid|.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
See Also: → bug 1215525
You need to log in before you can comment on or make changes to this bug.