| 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 |
| ========== |
| |
| - Rename glib-helper file to a more convenient name. The ideia is try to keep |
| only sdp helpers functions. bt_* prefix shall be also changed. |
| |
| Priority: Low |
| Complexity: C1 |
| |
| 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 |
| |
| - Define Auto Connection Establishment Procedure. Some profiles such as |
| Proximity requires an active link to identify path lost situation. It is |
| necessary to define how to manage connections, it seems that White List |
| is appropriated to address auto connections, however is not clear if the |
| this procedure shall be a profile specific detail or if the remote device |
| object can expose a property "WhiteList", maybe "Trusted" property can be |
| also used for this purpose. Another alternative is to define a method to |
| allow application to request/register the wanted scanning/connection |
| parameters. Before start this task, a RFC/PATCH shall be sent to the ML. |
| See Volume 3, Part C, section 9.3.5 for more information. |
| |
| Priority: Medium |
| Complexity: C2 |
| |
| - Implement a tool(or extend hciconfig) to setup the advertising parameters |
| and data. Extend hciconfig passing extra arguments when enabling the |
| advertises is not the right approach, it will be almost impossible to |
| address all arguments needed in an acceptable way. For testing, we need |
| a tool to change easily the AD Flags, the UUIDs and other data that can be |
| exported through the advertising data field. Suggestions: 1) extend hciconfig |
| passing a config file when enabling advertises; 2) write a ncurses based tool |
| |
| Priority: Medium |
| Complexity: C2 |
| |
| - Device Name Characteristic is a GAP characteristic for Low Energy. This |
| characteristic shall be integrated/used in the discovery procedure. The |
| ideia 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 |
| ======== |
| |
| - For BR/EDR, Discover All Primary Services shall be started after SDP if the |
| remote device exports a Generic Attribute Profile service record. It is |
| applied to CreateDevice and CreatePairedDevice. |
| |
| Priority: Medium |
| Complexity: C1 |
| |
| - Add ATT/GATT parsing to hcidump |
| |
| Priority: Medium |
| Complexity: C2 |
| |
| - GATT server: fix MTU exchange |
| |
| Priority: Medium |
| Complexity: C2 |
| |
| - gatttool: add an interactive command prompt mode. Many LE devices |
| expect the connection to stay up a long time and disable advertising |
| after a disconnection so it's inconvenient to use gatttool in the |
| current "single operation at a time" mode. |
| |
| Priority: Medium |
| Complexity: C2 |
| |
| - 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 |
| |
| - Refactoring of gatt.c functions. Currently, the callbacks of the services |
| and characteristics discovery functions return the ATT PDU and the caller |
| needs to call again the same function to fetch the remaining data when |
| necessary. Investigate if all results can be returned in the callback |
| result to avoid repeated code. Before change the code, please analyze |
| if this change will not break the GATT/ATT qualification tests. Maybe |
| an interactive fetch/query is necessary to pass the tests. |
| |
| 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 |
| |
| - Add sdp discovery support to gattool with BR (--sdp, default is 0x1f) |
| |
| Priority: Low |
| Complexity: 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 reads/writes don't work (consisting of multiple request packets) |
| |
| Priority: Low |
| Complexity: C2 |
| |
| - Implement Client Characteristic Configuration support in the attribute |
| server to manage indications and notications. This is a per client attribute |
| to control how the client wants to receive reports of changes in a given |
| characteristic value. |
| See Volume 3, Part G, section 3.3.3.3 for more information |
| |
| Priority: Low |
| Complexity: C2 |
| |
| - Define attribute server API. External applications needs to register, |
| change attributes and to be notified about changes. Example: Proximity, |
| Time and Alert Profiles. "Local Service hierarchy" in the attribute-api |
| needs to be proposed and a RFC shall be sent to the ML. |
| |
| Priority: Low |
| Complexity: C2 |
| |
| - gattrib needs to be extended to handle Attribute Protocol Transactions |
| timeout. See Volume 3, Part F, section 3.3.3 and Part G, section 4.14 |
| for more information. |
| |
| Priority: Low |
| Complexity: C2 |
