[GSoC] Week 3 (Native Bluetooth support)

[Dirk Hohndel]

On Wed, Jul 15, 2015 at 08:57:22AM +0200, Jef Driesen wrote:
> 
> Sorry for the slow response. Been busy with real life.

I know that feeling well.

> 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 :-)

I will let Nick comment on that if he wants to. I spent a lot of time
discussing implementation ideas with Nick in Fiji earlier this year and am
reasonably certain that my comments above are indeed correct.

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

Your definition of "patches are welcome" and my definition of that phrase
are very different. I respect your right to run your open source project
the way you see fit. I simply disagree with it. We talked about this at
length last fall in Duesseldorf and I won't try to rehash that
conversation here. But the perfectly functional, well tested and fairly
complete DC_FIELD_STRING implementation in our branch of Subsurface can
serve as a good example. So for a GSoC student to be dependent on any
changes making it into libdivecomputer is a complete non-starter. Which is
why I asked Claudiu to continue down the path he started on. And he's
making great progress.

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

Not at all. I want the ability to have that code in Subsurface BECAUSE I
don't want to add a Qt dependency to libdivecomputer. And because I don't
want to make my custom branch of libdivecomputer even more divergent from
your master branch than it already is. To me, the less code I need to add
to or change in libdivecomputer, the better.

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

Of course I want it for the Subsurface users. I am pushing for changes in
libdivecomputer that make it easier for the consumers of libdivecomputer
to give their users what they want. There is no reason to add dependencies
to libdivecomputer that are pointless for other consumers of that library.

I find this whole discussion very weird. I'm not asking you for anything
that would be Subsurface only. I'm not asking you to implement anything in
your library that others would be forced to use or would be unable to use.
I'm asking you to add a hook that allows each consumer comletely
optionally to provide their own communication layer.

> 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 :-(

Yes, just like MacDive today has a custom layer to communicate with the
Eon Steele and no other consumer of libdivecomputer can use that today.
Because Nick simply implements his own. He has his own communication layer
AND his own parser for the EON Steele. Feel free to doubt that statement
again and tell me that he's using libdivecomputer for that. I can promise
you that it isn't true.

I have access to his code and will eventually get around to figure out how
to use this in Subsurface within the constraints of the license he has
given it to me under. I completely respect his choice to do things this
way, it's his code. The current structure of libdivecomputer makes this
much harder, but I believe that with our callback mechanism I can quite
easily have Subsurface on a Mac call the necessary code in a library that
will allow us to communicate with the Eon Steele on a Mac as well.

So far I have seen zero user requests for this, so I'm focusing my time on
other things.

Anyway, allowing these callbacks isn't changing anything that isn't
happening already. What I want simply makes it easier to pick and chose
which part of libdivecomputer to use.

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

So you are telling me that you are not supporting this callback mechanism
because it would potentially cause a disadvantage to proprietary software.
That's your choice. It's your project.

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

To be perfectly honest, Jef, we have a working implementation in
Subsurface and our branch of libdivecomputer and right now I don't see any
advantage to spend more of my rather limited time working on this project
arguing with you and endlessly rewriting the code that we have until you
like it.

I know that people who read this and who haven't spent countless hours
trying to get code into libdiveomputer will see this as me not following
through on something that I should be engaging in. But I'll refer to my
comments above. Your definition of "I welcome outside contributions" is
simply so completely different from mine that I am too tired to try.

If you are interested in what we are doing, feel free to look at the code
in our branch. It's open source and you are more then welcome to use it
and change it as you see fit. Just like you took the Eon Steele code in
our branch (except for all the code that requires the DC_FIELD_STRING).

I will not hold up our development until we have found something that you
like and would like to incorporate into libdivecomputer. If you actually
end up doing something like that I will evaluate the API and decide if
it's worth my effort to migrate to it. Until that time I'll simply take
what Claudiu has developed and we will continue our development on top of
this.

For the record, we have working BT communication on Linux and Android and
appear to be fairly close on Mac. If we had waited for libdivecomputer we
would have nothing and Claudiu would have been unable to be successful in
his GSoC project.

/D