[GSoC] Week 3 (Native Bluetooth support)

[Dirk Hohndel]

On Mon, Jun 15, 2015 at 09:20:44PM +0300, Claudiu Olteanu wrote:
> >
> >
> >
> > 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.

The reason we explored QtBluetooth was that I was told that in Qt5.5 it
was going to support all our platforms. It appears that this was wrong an
it supports all except for Windows :-(

> 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.

You are right.

> 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.

OK. How are you going to implement the OS X Bluetooth stack in
libdiveceomputer? How about Android? And (here's hoping) IOS?

> 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.

Part of the appeal to implement BT in the application and not in
libdivecomputer is the whole question of a seamless experience to the user
when it comes to pairing with a device. The application creates the
communication and allows libdivecomputer to talk to the device through the
socket it opened...

/D