Add abstract BluetoothProfile class

device/bluetooth/bluetooth_profile.cc

Index: device/bluetooth/bluetooth_profile.cc
diff --git a/device/bluetooth/bluetooth_profile.cc b/device/bluetooth/bluetooth_profile.cc
new file mode 100644
index 0000000000000000000000000000000000000000..d4952951f229d9d7d61b408eb666b62729c8023d
--- /dev/null
+++ b/device/bluetooth/bluetooth_profile.cc
@@ -0,0 +1,29 @@
+// Copyright (c) 2013 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.
+
+#include "device/bluetooth/bluetooth_profile.h"
+
+#include <string>
+
+namespace device {
+
+BluetoothProfile::BluetoothProfile() {
+
+}
+
+BluetoothProfile::~BluetoothProfile() {
+

[youngki, 2013/04/11 18:33:41]

How about calling Unregister() in the destructor?

[keybuk, 2013/04/17 22:38:35]

The intent is that Unregister() *calls* the destructor - will clarify in the
comments

+}
+
+
+// static
+void BluetoothProfile::Register(const std::string& uuid,
+                                const ProfileCallback& callback) {
+  // TODO(keybuk): Implement selection of the appropriate BluetoothProfile
+  // subclass just like BluetoothAdapterFactory

[youngki, 2013/04/10 16:38:19]

Are we going to follow the similar structure as BluetoothAdapterFactory? If so
then we will have a lazy instance of a list of profiles in this file? shouldn't
we also make Unregister static? I can't clearly see how we could delete the
profile if Unregister() is a member function of BluetoothProfile.

[keybuk, 2013/04/17 22:38:35]

As discussed, No; it should be entirely okay to deal with that in other ways

+  callback.Run(NULL);
+}
+
+
+}  // namespace device