Background

==========

- Priority scale: High, Medium and Low

- Complexity scale: C1, C2, C4 and C8.  The complexity scale is exponential,

  with complexity 1 being the lowest complexity.  Complexity is a function

  of both task 'complexity' and task 'scope'.

  The general rule of thumb is that a complexity 1 task should take 1-2 weeks

  for a person very familiar with BlueZ codebase.  Higher complexity tasks

  require more time and have higher uncertainty.

  Higher complexity tasks should be refined into several lower complexity tasks

  once the task is better understood.

General

=======

- UUID handling: Use the new functions created for UUID handling in all parts

  of BlueZ code.  Currently, the new bt_uuid_* functions are being used by

  GATT-related code only.

  Priority: high

  Complexity: C4

- Update PBAP client/server implementation to 1.2 and create necessary APIs for

  new features it introduces.

  Priority: Medium

  Complexity: C4

- Create GOEP unit tests based on its test specification:

  https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=230559

  Priority: Medium

  Complexity: C2

- Function in src/adapter.c to convert old storage files to new ini-file format

  should be removed 6-8 months after first BlueZ 5 release.

  Priority: Low

  Complexity: C1

- Remove usage of symlinks for drivers, such as profiles/input/suspend.c and

  profiles/sap/sap.c. Instead, select drivers at runtime by using config

  options or probing for running D-Bus services (using e.g.

  g_dbus_add_service_watch()). Idea first mentioned on

  http://thread.gmane.org/gmane.linux.bluez.kernel/30175/focus=30190.

- Reuse connection handling code of src/profile.c also for built-in profiles

  so plugins would only need to register their btd_profile and the core takes

  care of the rest including listen to the right channel and manages the sdp

  record. Once btd_profile manages the connection it can also notify about

  their state, this probably remove the need of having callbacks to

  .connect/.disconnect since their state can be tracked, it also enables any

  plugin to track any profile state change which can be useful for e.g.

  a connection policy plugin in case one is needed.

  Priority: Low

  Complexity: C2

- Add queueing support for src/agent.c, currently if there is any request

  pending the code fail with error EBUSY which is very inconvenient.

  Priority: Low

  Complexity: C2

Low Energy

==========

- Connection modes. Adapter interface needs to be changed to manage

  connection modes and adapter type. See Volume 3, Part C, section 9.3.

  1. Mode management: Peripheral / Central

  Priority: Medium

  Complexity: C2

- Advertising data. The D-Bus interface needs to be updated to enable setting

  scan response data, and to read the advertising and scan response data which

  has been broadcast from other LE devices.

  Priority: Medium

  Complexity: C2

- Static random address setup and storage. Once this address is written

  in a given remote, the address can not be changed anymore.

  Priority: Low

  Complexity: C1

- Device Name Characteristic is a GAP characteristic for Low Energy. This

  characteristic shall be integrated/used in the discovery procedure. The

  idea is to report the value of this characteristic using DeviceFound signals.

  Discussion with the community is needed before to start this task. Other GAP

  characteristics for LE needs to follow a similar approach. It is not clear

  if all GAP characteristics can be exposed using properties instead of a primary

  service characteristics.

  See Volume 3, Part C, section 12.1 for more information.

  Priority: Low

  Complexity: C2

ATT/GATT (new shared stack)

===========================

- Add complete GATT test coverage in unit/test-gatt following the GATT test

  spec. This could use shared/gatt-client and shared/gatt-server at the same

  time to test both against eachother. We should definitely have tests for

  gatt-server and gatt-client simultaneously on one side of the connection.

  Priority: High

  Complexity: C4

- Write an example using client D-Bus API using C.

  Priority: High

  Complexity: C2

- Write an example using client D-Bus API using python.

  Priority: High

  Complexity: C2

- Define packed structs for ATT protocol PDUs in shared/att-types to improve

  readability. We should probably do this once there are extensive unit tests

  for gatt-client/gatt-server so that we don't accidentally break working code.

  Priority: Medium

  Complexity: C2

- Use struct iovec to pass around byte buffers that will be sent over the wire,

  instead of passing uint8_t and size_t parameters everywhere.

  Priority: Medium

  Complexity: C1

- Move all daemon plugins and profiles that are GATT based to use

  shared/gatt-client instead of attrib/*. This is a complicated task that

  potentially needs a new plugin/profile probing interface and a lot of

  rewriting that can cause regressions in existing functionality.

  Priority: Medium

  Complexity: C4

- Introduce a way for shared/gatt-server to check security permissions on the

  current connection through bt_att.

  Priority: Medium

  Complexity: C2

- Implement other low-priority ATT protocol operations for shared/gatt-server:

      Read Multiple Request

  Priority: Low

  Complexity: C1

- Send out indications from the "Service Changed" characteristic upon

  reconnection if a bonded device is not connected when the local database is

  modified.

  Priority: High

  Complexity: C2

- Unify the GATT server and client D-Bus implementations into a single module.

  While these don't share a lot of code, keeping them all in src/gatt-dbus seems

  to make more sense from an organizational perspective.

  Priority: Low

  Complexity: C1

- Isolate all GATT code inside the daemon into its own module and perform

  interaction with other modules (e.g. src/device.c) via callbacks. This

  includes client/server management, tracking incoming/outgoing connections for

  ATT, and callbacks to perform profile probing.

  Priority: Low

  Complexity: C4

- Support included services in the GATT D-Bus client API.

  Priority: Medium

  Complexity: C1

Management Interface

====================

Mesh

====

- Read default configuration settings (e.g., provisioning timeout, supported

  features, etc.)from  mesh.conf file.

  Priority: Medium

  Complexity: C1

- Add examples and unit tests

  Priority: High

  Complexity: C1

- Implement unified feature management mechanism for mesh nodes that are hosted

  on the same device

  Priority: Medium

  Complexity: C2

- Implement mandatory Health Server model. Most likely, this will involve

  additions to mesh D-Bus API

  Priority: Medium

  Complexity: C2

- Design and implement Mesh Provisioner/ Configuration Client Model.

  Priority: Medium

  Complexity: C4

- Add support for GATT proxy server

  Priority: Low

  Complexity: C4

- Merge common functionality from tools/mesh. Ideally, source code from the

  tools/mesh directory should completely dissapear.

  Priority: Low

  Complexity: C2

- Support for Low Power Node (LPN)

  Priority: Low

  Complexity: C4

- Support for all the provisioning OOB types

  Priority: Medium

  Complexity: C2