[GSoC] Week 3 (Native Bluetooth support)

[Jef Driesen]

Dirk,

Sorry for the slow response. Been busy with real life.

On 2015-06-17 16:45, Dirk Hohndel wrote:
> I don't know which other apps use libdivecomputer, but the ones that I
> know about...
> 
> Subsurface: happy to implement a Bluetooth backend, happy to use the
> existing libdivecomputer communication layer otherwise
> 
> MacDive: doesn't use libdivecomputer at all for communication and only
> uses some of your parsers

I think you are mistaken here. As far as I know, Macdive does use 
libdivecomputer for the communication (except for the cobalt I believe). 
You are right that Macdive has a few custom parsers, but that's mainly 
for historic reasons. Back in the early days, libdivecomputer didn't 
support some features that MacDive needed. Nowadays we support most of 
them, but you know: if it ain't broken don't fix it :-)

> DivingLog: wouldn't know which end of a C library is up and therefore 
> has
> you do all his work for him. Couldn't implement a low-level I/O 
> function
> to save his business model
> 
> (OK, that was harsh, but I'll be interested in someone proving me 
> wrong)

Anyone is free to use his/her preferred programming language for his/her 
own project, right? I can't write an application in assembler (and many 
other programming languages) either :-)

I'm sure it will be possible to write a low-level I/O backend in .NET 
too.

> Who else?

There are many more. I maintain a (possible incomplete) list on the 
libdivecomputer website:

http://libdivecomputer.org/links.html#applications

> My point is... does the fact that you implement all of the dive 
> computer
> code for DivingLog impact your view of what other applications might 
> want
> from libdivecomputer?

No it doesn't. I think you greatly overestimate my involvement with 
Diving Log. Yes, I did spend quite some time to figure out how to use 
libdivecomputer from .NET code (and by doing that I learned how to make 
sure that the public api is usable from non C/C++ code). But that's 
already several years ago. Nowadays it's limited to building the 
libdivecomputer dll and notifying Sven about changes when necessary. I 
have (and need) the windows build setup anyway, so why not? It's just a 
few minutes of work once in a while.

> And applications benefit from being able to add things that aren't in
> libdivecomputer and that likely won't be in libdivecomputer for a 
> loooong
> time. When do you think your Android Bluetooth support will be ready to
> ship? What about your Mac Bluetooth support?
> 
> If we can have a callback into the app then we'll have both working in
> Subsurface by the end of this summer.

I think you already know my answer: I have no idea, but definitely not 
by the end of this summer. (Note that a callback based interface won't 
be available by that time either.) But nobody says you have to wait 
until *I* have time to implement some code for Android, Mac or whatever 
OS. Patches with support for those OS'es are always welcome...

I'm aware there are good technical arguments in favor of a custom I/O 
layer too. For example a Qt based application like subsurface can easily 
take advantage of the bluetooth support in the Qt framework, while other 
applications may not appreciate such a (huge) dependency. But that's 
another story.

>> 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!)
> 
> You are missing the point. Really. We are not saying "stop doing it in
> libdivecomputer". We are saying "offer the app a chance to register a
> callback". If it's there, use it. If it isn't, do what you are doing
> today.

That was a bit of a misunderstanding then. I initially understood you 
wanted to keep all bluetooth code out of libdivecomputer, and have the 
custom backend as the only option.

>> 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.
> 
> Because you don't understand how other apps besides DivingLog want to 
> use
> your library. If it's not available on Mac it doesn't help about a 
> quarter
> of my users. And I expect that by the end of summer we'll have an 
> Android
> app as well and I'll bet good money that that will be quite popular 
> very
> quickly. And the main reason all the dive computer vendors are coming 
> out
> with BT devices is because it's so hard to do USB downloads on Android 
> and
> IOS.

So you want this functionality for *YOUR* users. Am I right that you 
probably don't really care much about other applications? Although I can 
understand such point of view, that's exactly the point I wanted to 
make!

Let's assume for a moment that libdivecomputer supports custom I/O 
implementations. Now, if one application (let's call it "X") implements 
its own low-level bluetooth I/O for Mac, then only the users of that 
specific application will be able to use bluetooth devices. But all 
other Mac applications will still be left without bluetooth support! No 
doubt I'll quickly start receiving questions why application X supports 
this, but not their favourite application :-(

[This is already the case today. IrDA devices (Uwatec Smart/Galileo) are 
not supported on Mac either. I certainly get questions about that on a 
regular basis, and I'm sure you get them from subsurface users too.]

Now, if this application is an open source application, like subsurface, 
then other (open source) applications can easily re-use the low level 
I/O code. In that case I don't mind at all. (Just like I don't mind you 
are currently using a modified libdivecomputer for subsurface.) But 
remember that libdivecomputer is also used by (many) closed source 
applications! If one those closed source applications implements a 
custom I/O backend, then that gives them a competitive advantage, while 
nobody else can re-use their work. That's the kind of situation I don't 
like.

Right now, anyone modifying libdivecomputer without making those 
modifications available, is strictly speaking violating the lgpl 
license. But once libdivecomputer provides the infrastructure for custom 
I/O backends, then that's no longer the case. That's the main reason why 
I'm a bit sceptical about supporting custom I/O. Does that mean I won't 
consider this idea? Of course not!

On the technical side, I'm sure we can work out the details and come up 
with a solution that does satisfy the needs of both applications and 
libdivecomputer. See for example the proposal in one of my previous 
emails [1].

[1] 
http://lists.subsurface-divelog.org/pipermail/subsurface/2015-June/019984.html

Jef