TODO

   1 Background
   2 ==========
   3
   4 - Priority scale: High, Medium and Low
   5
   6 - Complexity scale: C1, C2, C4 and C8.  The complexity scale is exponential,
   7   with complexity 1 being the lowest complexity.  Complexity is a function
   8   of both task 'complexity' and task 'scope'.
   9
  10   The general rule of thumb is that a complexity 1 task should take 1-2 weeks
  11   for a person very familiar with BlueZ codebase.  Higher complexity tasks
  12   require more time and have higher uncertainty.
  13
  14   Higher complexity tasks should be refined into several lower complexity tasks
  15   once the task is better understood.
  16
  17 General
  18 =======
  19
  20 - UUID handling: Use the new functions created for UUID handling in all parts
  21   of BlueZ code.  Currently, the new bt_uuid_* functions are being used by
  22   GATT-related code only.
  23
  24   Priority: high
  25   Complexity: C4
  26
  27 - Update PBAP client/server implementation to 1.2 and create necessary APIs for
  28   new features it introduces.
  29
  30   Priority: Medium
  31   Complexity: C4
  32
  33 - Create GOEP unit tests based on its test specification:
  34
  35   https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=230559
  36
  37   Priority: Medium
  38   Complexity: C2
  39
  40 - Function in src/adapter.c to convert old storage files to new ini-file format
  41   should be removed 6-8 months after first BlueZ 5 release.
  42
  43   Priority: Low
  44   Complexity: C1
  45
  46 - Remove usage of symlinks for drivers, such as profiles/input/suspend.c and
  47   profiles/sap/sap.c. Instead, select drivers at runtime by using config
  48   options or probing for running D-Bus services (using e.g.
  49   g_dbus_add_service_watch()). Idea first mentioned on
  50   http://thread.gmane.org/gmane.linux.bluez.kernel/30175/focus=30190.
  51
  52 - Reuse connection handling code of src/profile.c also for built-in profiles
  53   so plugins would only need to register their btd_profile and the core takes
  54   care of the rest including listen to the right channel and manages the sdp
  55   record. Once btd_profile manages the connection it can also notify about
  56   their state, this probably remove the need of having callbacks to
  57   .connect/.disconnect since their state can be tracked, it also enables any
  58   plugin to track any profile state change which can be useful for e.g.
  59   a connection policy plugin in case one is needed.
  60
  61   Priority: Low
  62   Complexity: C2
  63
  64 - Add queueing support for src/agent.c, currently if there is any request
  65   pending the code fail with error EBUSY which is very inconvenient.
  66
  67   Priority: Low
  68   Complexity: C2
  69
  70 Low Energy
  71 ==========
  72
  73 - Connection modes. Adapter interface needs to be changed to manage
  74   connection modes and adapter type. See Volume 3, Part C, section 9.3.
  75   1. Mode management: Peripheral / Central
  76
  77   Priority: Medium
  78   Complexity: C2
  79
  80 - Advertising data. The D-Bus interface needs to be updated to enable setting
  81   scan response data, and to read the advertising and scan response data which
  82   has been broadcast from other LE devices.
  83
  84   Priority: Medium
  85   Complexity: C2
  86
  87 - Static random address setup and storage. Once this address is written
  88   in a given remote, the address can not be changed anymore.
  89
  90   Priority: Low
  91   Complexity: C1
  92
  93 - Device Name Characteristic is a GAP characteristic for Low Energy. This
  94   characteristic shall be integrated/used in the discovery procedure. The
  95   idea is to report the value of this characteristic using DeviceFound signals.
  96   Discussion with the community is needed before to start this task. Other GAP
  97   characteristics for LE needs to follow a similar approach. It is not clear
  98   if all GAP characteristics can be exposed using properties instead of a primary
  99   service characteristics.
 100   See Volume 3, Part C, section 12.1 for more information.
 101
 102   Priority: Low
 103   Complexity: C2
 104
 105 ATT/GATT (new shared stack)
 106 ===========================
 107
 108 - Add complete GATT test coverage in unit/test-gatt following the GATT test
 109   spec. This could use shared/gatt-client and shared/gatt-server at the same
 110   time to test both against eachother. We should definitely have tests for
 111   gatt-server and gatt-client simultaneously on one side of the connection.
 112
 113   Priority: High
 114   Complexity: C4
 115
 116 - Write an example using client D-Bus API using C.
 117
 118   Priority: High
 119   Complexity: C2
 120
 121 - Write an example using client D-Bus API using python.
 122
 123   Priority: High
 124   Complexity: C2
 125
 126 - Define packed structs for ATT protocol PDUs in shared/att-types to improve
 127   readability. We should probably do this once there are extensive unit tests
 128   for gatt-client/gatt-server so that we don't accidentally break working code.
 129
 130   Priority: Medium
 131   Complexity: C2
 132
 133 - Use struct iovec to pass around byte buffers that will be sent over the wire,
 134   instead of passing uint8_t and size_t parameters everywhere.
 135
 136   Priority: Medium
 137   Complexity: C1
 138
 139 - Move all daemon plugins and profiles that are GATT based to use
 140   shared/gatt-client instead of attrib/*. This is a complicated task that
 141   potentially needs a new plugin/profile probing interface and a lot of
 142   rewriting that can cause regressions in existing functionality.
 143
 144   Priority: Medium
 145   Complexity: C4
 146
 147 - Introduce a way for shared/gatt-server to check security permissions on the
 148   current connection through bt_att.
 149
 150   Priority: Medium
 151   Complexity: C2
 152
 153 - Implement other low-priority ATT protocol operations for shared/gatt-server:
 154
 155       Read Multiple Request
 156
 157   Priority: Low
 158   Complexity: C1
 159
 160 - Send out indications from the "Service Changed" characteristic upon
 161   reconnection if a bonded device is not connected when the local database is
 162   modified.
 163
 164   Priority: High
 165   Complexity: C2
 166
 167 - Unify the GATT server and client D-Bus implementations into a single module.
 168   While these don't share a lot of code, keeping them all in src/gatt-dbus seems
 169   to make more sense from an organizational perspective.
 170
 171   Priority: Low
 172   Complexity: C1
 173
 174 - Isolate all GATT code inside the daemon into its own module and perform
 175   interaction with other modules (e.g. src/device.c) via callbacks. This
 176   includes client/server management, tracking incoming/outgoing connections for
 177   ATT, and callbacks to perform profile probing.
 178
 179   Priority: Low
 180   Complexity: C4
 181
 182 - Support included services in the GATT D-Bus client API.
 183
 184   Priority: Medium
 185   Complexity: C1
 186
 187 Management Interface
 188 ====================