On Mon, Jun 15, 2015 at 12:19:32PM +0300, Claudiu Olteanu wrote: > Ok. In the beginning I will try to implement the downloading > entirely in Subsurface and re-implement the dive computer > protocol for HW OSTC family. > > To be honest I believe that a better idea would be to > continue the work you started and to use directly > the BlueZ stack instead of Qt Bluetooth API. In this > way I won't re-implement the dive computer communication > protocol, I will add Bluetooth support to libdivecomputer > and I will use it in the Subsurface project. > The only thing I can't imagine is how libdivecomputer > will expose functionalities like pairing/scanning/hci control.
Part of what you are learning in GSoC is that sometimes we start projects with incorrect assumptions and as we understand problems better we come up with different solutions. It is entirely reasonable for you to say "the initial design idea was wrong, here's a better approach how to do this". I am not at all opposed to turn this into a project that includes modifications to libdivecomputer instead. Given the lack of Bt support on Windows when just using bluez I wonder if there is value in Anton's idea to modify libdivecomputer to use a callback to open a serial connection and then have Subsurface (or other consumers of libdivecomputer) provide that serial stream back to libdivecomputer. This way we could still use QtBluetooth on the Subsurface side but benefit from the libdivecomputer download algorithms. Does this seem like a reasonable direction? /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface