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