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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
