[GSoC] Week 3 (Native Bluetooth support)

[Jef Driesen]

On 2015-06-15 20:26, Thiago Macieira wrote:
> On Monday 15 June 2015 06:13:54 Dirk Hohndel wrote:
>> On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote:
>> > I did already think about this :-) See [1] for some more background info.
>> >
>> > In a nutshell, the serial layer will be changed from a concrete
>> > implementation into an abstract interface. This will allow us to have
>> > multiple implementations: native (using kernel drivers), bluetooth (using
>> > rfcomm sockets), usb-serial (cdc-acm, ftdi, pl2303, cp210x), etc
>> 
>> What about allowing the calling application to handle the creation of 
>> a
>> serial communication stream and simply providing a callback to do so?
>> 
>> Or am I missing another implementation issue here (it's been too long 
>> that
>> I dug deeply into that part of libdivecomputer code)
> 
> Right.
> 
> Jef, can we have an API that allows the application to pass a set of 
> function
> pointer callbacks for all the operations that libdc needs to do? Assume 
> that
> the device. You probably need open, close, read, write, but what else?
> 
> This way, the application can redirect the I/O through whichever other 
> means
> it has at its disposal.

I'm not convinced application provided callback functions are the right 
solution, for the following reasons:

1. If the application has to provide the low-level I/O functions, that 
means *every* single application will have to re-implement this 
functionality on its own. That will require a significant amount of 
extra work, especially when the low-level I/O is not trivial. And the 
fact that we are having this discussion is definitely a sign that 
bluetooth communication is not trivial. That's why I believe 
libdivecomputer should provide the low-level communication. All 
applications will benefit from having a common implementation.

2. If applications are responsible for the low-level communication, then 
the list of supported dive computers will depend on which protocols have 
been implemented by the application. Thus two applications using the 
same libdivecomputer library may not support the same set of dive 
computers. That's not only confusing, but may also give closed source 
applications a competitive advantage: A closed source application could 
implement a low-level communication backend and decide not to share it 
with everyone else. (This might be considered an ideological issue, and 
not a technical one. But since this happens to be one of the reason why 
libdivecomputer is an open source library, this matters to me!)

3. Right now, the api for the low-level communication is a private api. 
This has several advantages. First of all, that allows me to change the 
api when necessary, without having to worry about backwards 
compatibility. Once I provide some callback interface, that will become 
part of the public api. But that's not all.

Second, and even more important, is that a custom communication backend 
won't be able to take advantage of other internal api's, like the 
logging infrastructure. That's a really important feature for me, 
because it greatly simplifies troubleshooting and debugging.

4. We already have a working proof of concept for native bluetooth 
communication, which supports Linux and Windows. So I don't see any 
reasons why we would need a custom implementation there.

If Qt supports discovery, pairing, etc there is nothing preventing you 
from using those features, and let libdivecomputer take care of the 
actual communication. I quickly checked the Qt implementation for Linux, 
and they are using the same socket based api as my proof of concept. So 
under the hood it's the same.

I'm also not ruling out an (optional) dependency on Qt for the other 
platforms like Mac OS X, iOS, Android.

Jef