On 2017-03-16 17:45, Jef Driesen wrote:
I'm planning some major non-backwards compatible changes for the next release. The first one is a refactoring of the I/O layer to support bluetooth communication (and more). The remainder of this email contains a description of the problem and a proposal for how I would like to address this.
[...]
I've implemented a first version of the new I/O layer api. See the attached patches for details. To see what needs to change on the application side, patch #0007 is the most interesting one.
Note that there are several areas that will need some more polish, in particular:
1. Device discovery built-in filtering
Because the device discovery is now moved to the application, also some of this logic was moved to the application. For example the Uwatec discovery detects Uwatec dive computer based on a set of well known IrDA device names. But ideally only libdivecomputer should need to know those IrDA names.
This could be achieved by providing some built-in filtering based on the device descriptor. Thus if the application enumerates the IrDA devices, and passes a Uwatec device descriptor, the discovery would only return those devices that matches Uwatec names.
This can easily be extended for the other built-in transport protocols like USB HID (filtering on VID/PID), bluetooth (filtering on device name), etc.
So that means the discovery api will still change significantly.
2. Multiple transport types per device descriptor
At the moment each device descriptor can support only one transport type. But there are devices that support multiple transport protocols. For example all classic bluetooth (rfcomm) devices also support serial communication. This could be supported by changing the transport type into a bitfield. This will also require some changes on the application side.
3. Api to query the built-in I/O implementations
At the moment there is no mechanism to detect whether a particular I/O implementation is available. The functions are always available, and if not supported, they will fail with DC_STATUS_UNSUPPORTED when trying to use them. But it will certainly be more user friendly if an application can query libdivecomputer in advance and hide stuff that is not supported.
An alternative could be to not report a transport type if the corresponding built-in I/O implementation isn't available. But that might be less ideal for applications using a custom I/O implementation. If an application chooses to use a custom bluetooth implementation if the built-in one isn't available, then it probably still wants to know the device supports bluetooth communication, right?
I'm not sure yet what would be the best way to deal with this. Ideas is welcome.
4. No custom I/O layer yet
I haven't added the support for a custom I/O implementation yet. That's still on my todo list.
5. USB communication
The Atomic Aquatics Cobalt has not been ported to the new I/O layer, because USB communication doesn't really map nicely onto the api. As an exception to the rule, the application will need to pass a NULL pointer. The transport type is probably best changed to DC_TRANSPORT_NONE to reflect this. I don't really have another solution for this case.
Jef