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. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface