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

Low Energy
==========

- Advertising management. Adapter interface needs to be changed to manage
  connection modes, adapter type and advertising policy. See Volume 3,
  Part C, section 9.3. If Attribute Server is enabled the LE capable
  adapter shall to start advertising. Further investigation is necessary
  to define which connectable mode needs to be supported: Non-connectable,
  directed connectable and undirected connectable. Basically, two connectable
  scenarios shall be addressed:
  1. GATT client is disconnected, but intends to become a Peripheral to
     receive indications/notifications.
  2. GATT server intends to accept connections.

  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

- Persist client attribute cache across reboots.

  Priority: Medium
  Complexity: C4

- 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

- Implement the server portion of doc/gatt-api.txt using shared/gatt-server once
  it exists.

  Priority: Medium
  Complexity: C4

- 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

- The recently added support for ATT signed writes requires the following kernel
  modules to be enabled:

     CONFIG_CRYPTO_USER_API
     CONFIG_CRYPTO_USER_API_HASH
     CONFIG_CRYPTO_USER_API_SKCIPHER

  Currently, if these are not enabled, bt_att_new silently returns NULL. We
  should handle this more gracefully by not supporting signed writes if we can't
  initialize bt_crypto while succeeding bt_att initialization regardless.

  This behavior should be documented in the README.

  Priority: High
  Complexity: C1


ATT/GATT (old/outdated)
=======================

- At the moment authentication and authorization is not supported at the
  same time, read/write requirements in the attribute server needs to
  be extended. According to Bluetooth Specification a server shall check
  authentication and authorization requirements before any other check is
  performed.

  Priority: Medium
  Complexity: C1

- Implement ATT PDU validation. Malformed PDUs can cause division by zero
  when decoding PDUs. A proper error PDU should be returned for this case.
  See decoding function in att.c file.

  Priority: Medium
  Complexity: C1

- Refactor read_by_group() and read_by_type() in src/attrib-server.c
  (they've grown simply too big). First step could be to move out the
  long for-loops to new functions called e.g. get_groups() and get_types().

  Priority: Low
  Complexity: C1

- Agent for characteristics: Agent interface should be extended to support
  authorization per characteristic if the remote is not in the trusted list.

  Priority: Low
  Complexity: C1

- gatttool should have the ability to wait for req responses before
  quitting (some servers require a small sleep even with cmd's). Maybe a
  --delay-exit or --timeout command line switch.

  Priority: Low
  Complexity: C1

- Client needs to export a property in the Device Characteristic hierarchy
  to manage characteristic value changes reports in the remote device.
  Currently, Client Characteristic Configuration attribute is not exposed
  as an object. The user needs to use gatttool to change the value of the
  this attribute to receive notification/indications. Export this attribute
  as a property is a proposal that needs further discussion.

  Priority: Low
  Complexity: C1

- Attribute server should process queued GATT/ATT commands if the
  client disconnects. The client can simply send a command and quit,
  without wait for a response(ex: Write Command). For this scenario
  that the client disconnects the link quickly the queued received
  command is ignored.

  Priority: Low
  Complecity: C1

- Implement Server characteristic Configuration support in the attribute
  server to manage characteristic value broadcasting. There is a single
  instance of the Server Characteristic Configuration for all clients.
  See Volume 3, Part G, section 3.3.3.4 for more information.

  Priority: Low
  Complexity: C1

- Long write is not implemented. Attribute server, client and command line
  tool shall be changed to support this feature.

  Priority: Low
  Complexity: C2

Management Interface
====================