Qt Bluetooth in 5.5

[Jef Driesen]

On 2015-03-19 14:23, Lubomir I. Ivanov wrote:
> On 18 March 2015 at 05:48, Dirk Hohndel <dirk at hohndel.org> wrote:
>> 
>> Thiago,
>> 
>> would Subsurface benefit from using Qt Bluetooth for our intended 
>> Bluetooth integration?
>> This would cause some interesting architectural challenges with 
>> libdivecomputer (as that most definitely doesn’t want to depend on 
>> Qt), but I find it very intriguing that Qt now supports all of the 
>> platforms we are interested in… or am I missing something here?
>> 
> 
> i can see that libDC has a parser API exposed, but i don't know if /
> how does that works, but if Subsurface uses Qt's BT it can in theory
> just use libDC as a parser (Thiago mentioned the same).

It works (almost) exactly the same as for data downloaded from a dive 
computer. The parser doesn't care whether the data was downloaded with 
libdivecomputer or not.

There is only one extra complication. After downloading the dives with 
libdivecomputer, you typically use the dc_parser_new() function to 
create the parser. For parser backends that require some additional 
metadata (e.g. model number and clock synchronization timestamps), this 
function will automatically take care of transferring the metadata from 
the device layer to the parser. That's something you'll have to do 
manually.

> i think it would be better for the student to first help Jeff get the
> BT working in libDC for Win32 and Linux and then start working on the
> Subsurface side.

My prototype code is almost fully functional at this point. What's 
lacking is the proper integration in the libdivecomputer api. The way I 
did this for the prototype (with #ifdef's) is nothing more than a 
temporary hack. I have some ideas on how to do this properly (see 
details below). But this will require some major redesign of the api, 
and therefore will have to be postponed until after the next v0.5 
release.

The main idea for the api change is as follows. Instead of passing the 
name of the serial port to the dc_device_open() function, and let 
libdivecomputer open the serial port internally, this will now be 
delegated to the application:

dc_serial_t *serial = NULL;
dc_device_t *device = NULL;

/* Open the serial port. */
dc_serial_open(&serial, devname);

/* Open a connection to the device. */
dc_device_open(&device, context, descriptor, serial);

/* TODO: Download dives here (same as before). */

/* Free resources */
dc_device_close(device);
dc_serial_close(serial);

The main benefit is that this change will allow us to pass something 
else than just a string (with the name of the serial port). For devices 
that use bluetooth communication, the application opens a bluetooth 
socket, and passes that to the dc_device_open() function:

dc_bluetooth_t *bluetooth = NULL;

/* Open a bluetooth socket. */
dc_bluetooth_open(&bluetooth, macaddress);

/* Open a connection to the device. */
dc_device_open(&device, context, descriptor, bluetooth);

Note that applications can query the device descriptor to figure out 
whether a device uses serial or bluetooth communication. That 
functionality is already present.


There are two other important advantages too. This will also allow us to 
expose the built-in serial port enumeration (and for bluetooth the 
device discovery) to the application. It will also makes it possible to 
implement user-space serial drivers for mobile devices (e.g. Android and 
iOS) where we typically don't have the required usb-serial kernel 
drivers.

> but...if the OSX code is not going to be donated soon (or maintained
> well in that aspect), i suggest we just use Qt's BT.

As Dirk mentioned, a dependency on Qt is far from ideal for 
libdivecomputer. So I would like to avoid that. But at the moment I see 
no reason to use Qt on Windows and Linux. The main problem will be Mac 
OS X. But I think that if we can already support bluetooth on Windows 
and Linux, that would already be a nice improvement. Worst case 
scenario, Mac users will have to stick with the serial emulation a bit 
longer.

> there is also the option for libDC to expose API to allow the libDC
> user to specify the BT backend (e.g.. built-in VS external C-wrapped
> Qt BT), but that's probably a ton of extra work for Jeff.

I already considered this, but I believe it's a very bad idea in the 
long term. Because the low level communication is maintained as a 
built-in backend today, all applications are equal and are able to 
support the same set of devices. But that will no longer be true when 
applications can use their own backend. Then you'll end up with a 
situation where application X can support a certain device, while 
application Y can't. Remember that not all libdivecomputer based 
applications are open source! (Note that I don't mind closed source apps 
using libdivecomputer. But I do mind closed source improvements that are 
not contributed back. I picked the LGPL license for a reason.)

Jef