bluetooth: browser-side implementation of writeValue.

content/common/bluetooth/bluetooth_messages.h

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Messages for Web Bluetooth API.
 // Multiply-included message file, hence no include guard.
 
 // Web Bluetooth Security
 // The security mechanisms of Bluetooth are described in the specification:
 // https://webbluetoothchrome.github.io/web-bluetooth
@@ skipping 157 matching lines @@
                      int /* request_id */,
                      std::vector<uint8_t> /* value */)
 
 // Informs the renderer that an error occurred while reading the value.
 IPC_MESSAGE_CONTROL4(BluetoothMsg_ReadCharacteristicValueError,
                      int /* thread_id */,
                      int /* request_id */,
                      content::BluetoothError /* result */,
                      std::string /* error_message */)
 
+// Informs the renderer that the value has been successfully written to
+// the characteristic.
+IPC_MESSAGE_CONTROL2(BluetoothMsg_WriteCharacteristicValueSuccess,
+                     int /* thread_id */,
+                     int /* request_id */)
+
+// Informs the renderer that an error occurred while writing a value to a
+// characteristic.
+IPC_MESSAGE_CONTROL4(BluetoothMsg_WriteCharacteristicValueError,
+                     int /* thread_id */,
+                     int /* request_id */,
+                     content::BluetoothError /* result */,
+                     std::string /* error_message */)

[palmer, 2015/07/07 21:37:17]

It's generally best (smaller messages, faster) to send an error code enum and
let the recipient translate the enum value into a string at its appropriate UI
layer. The concern is more acute when the message is renderer -> browser (we
don't like to let renderers control what data is in browser memory any more than
necessary), but it's still a good practice regardless of message direction.

[ortuno, 2015/07/07 22:01:52]

I considered that pattern, but there are 25 different error messages and having
such a big enum on both sides seemed unnecessary. I'm happy to use an enum
instead if you think it's necessary. Since this would be a non trivial
refactoring would it be OK to do it in a follow up CL?

+
 // Messages sent from the renderer to the browser.
 
 // Requests a bluetooth device from the browser.
 // TODO(scheib): UI to select and permit access to a device crbug.com/436280.
 //   This will include refactoring messages to be associated with an origin
 //   and making this initial requestDevice call with an associated frame.
 //   This work is deferred to simplify initial prototype patches.
 //   The Bluetooth feature, and the BluetoothDispatcherHost are behind
 //   the --enable-experimental-web-platform-features flag.
 IPC_MESSAGE_CONTROL4(BluetoothHostMsg_RequestDevice,
@@ skipping 20 matching lines @@
                      int /* thread_id */,
                      int /* request_id */,
                      std::string /* service_instance_id */,
                      std::string /* characteristic_uuid */)
 
 // Reads the characteristics value from a bluetooth device.
 IPC_MESSAGE_CONTROL3(BluetoothHostMsg_ReadValue,
                      int /* thread_id */,
                      int /* request_id */,
                      std::string /* characteristic_instance_id */)
+
+// Writes a value to a bluetooth device's characteristic.
+IPC_MESSAGE_CONTROL4(BluetoothHostMsg_WriteValue,
+                     int /* thread_id */,
+                     int /* request_id */,
+                     std::string /* characteristic_instance_id */,
+                     std::vector<uint8_t> /* value */)