On Wed, Jun 17, 2015 at 04:20:42PM +0200, Jef Driesen wrote: > 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
No one suggested that the application HAS to provide that functionality. What we are suggesting is to make this an OPTION. If the application wants to do this... 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 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) Who else? 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? > *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. 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. > 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. This way our download dialog can have a button "use Bluetooth". If that's clicked we register the callbacks and do the communication ourselves. If it isn't, we use libdivecomputer just like we do today. > 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. > 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. Having a library depend on Qt. Interesting concept. I'm open to many ideas to support this. But I'm also more than willing to simply add the necessary callbacks to the Subsurface-testing branch of libdivecomputer that all of our binaries are built against. /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
