[GSoC] Week 3 (Native Bluetooth support)

[Claudiu Olteanu]

>
>
>
> Given the lack of Bt support on Windows when just using bluez I wonder if
> there is value in Anton's idea to modify libdivecomputer to use a callback
> to open a serial connection and then have Subsurface (or other consumers
> of libdivecomputer) provide that serial stream back to libdivecomputer.
>
> This way we could still use QtBluetooth on the Subsurface side but benefit
> from the libdivecomputer download algorithms.
>
> Does this seem like a reasonable direction?
>
> /D
>


Yes, it is a reasonable direction but I have to remind you
that *QtBluetooth* doesn't have support for Windows. They
probably started to work on it [1] but there is no information
about the release date.

Therefore for Windows we should use the *MS Bluetooth* stack.
The same technology is used/will be used in *libdivecomputer*
project. The only benefit with *QtBluetooth* API is that it
has support for OSx, iOS, Android and Linux.

I am not against *QtBluetooth* API, because I am already
accommodated with the API but I believe that it would be more
beneficial for both projects to have the Bluetooth implementation
in the *libdivecomputer* project, since it is already started.

I am a little confused about which direction to go. I read the
link suggested by Jef and there are some drawbacks mentioned.
Also, the discussions were from 2014 and I don't know if
any idea from there was taken into consideration
and it will be used in a new release. I remember that Jef said
that he intends to do some major changes on the API in the next
release.

Also I believe that it would be helpful if the new API will
allow applications to open the low-level communication
transport (already implemented in the *libdivecomputer*, like Jef
suggested) or to open a custom one implemented in the application
which respects the same layout (like Anton suggested). It will
require some extra code in the application side but it will
cover a lot of usages. In this way we can create our custom
implementation with the *QtBluetooth* API for its supported
platforms, while for Windows we can finish the implementation
from the *libdivecomputer* project.

The applications will be responsible to implement features
like pairing/scanning/hci control if they want to use Bluetooth
protocol for communication and extract the address of the remote
device. The job of the *libdivecomputer* will be to assure the
communication and the data parsing. It will not be its responsibility
to enumerate serial, usb or bluetooth devices or to expose an
API to control the devices.

[1] - https://bugreports.qt.io/browse/QTBUG-40698

Claudiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150615/cffca141/attachment.html>