During the time we worked with BlueZ HDP development, we felt the lack of two things: counterparts to talk with (that is, devices and operating systems that implemented HDP) and high-level tools.
Another problem was the novelties that HDP demanded: enhanced L2CAP, MCAP etc. When an error occurs, it was difficult to find where it was. Could be at kernel, at BlueZ, at MCAP or in HDP itself.
That's why we put together HDPy. It is a "clean-room", pure-Python implementation of HDP (and MCAP and CSP). It depends on a recent Linux kernel (for eL2CAP), the CVS version of PyBlueZ, and nothing more. It even passes the PTS tests!
For now, it works in Linux only, due the usage of Bluetooth sockets and eL2CAP features. It is enough for us. But nothing prevents it to be ported to other operating systems, once eL2CAP is available on them. Some scripts do use GLib as main loop, but the modules themselves do not impose GLib, the application may use any event loop, or threads.
This video shows the oximeter connecting to a HDPy-powered sink:
The HDP API is very similar to BlueZ D-Bus API. This is intentional; it is a way to share scripts between them with very few changes, and was once employed as a way to validate the proposed BlueZ API, to make sure it would be feature-complete and easy to use. On top of that, there is a complete MCAP and CSP API.
HDPy was also employed as a "cradle" for CSP. CSP was developed "by the book", like all software "should" be developed: first we made it work in HDPy, and once it looked good, it was translated to C, to fit in BlueZ framework.
We have been using it as a kind of repository for some BlueZ-HDP related things, like recent versions of software packages that HDP needs (like D-Bus 1.4), as well as a small collection of BlueZ-HDP scripts, like the one I showed two posts ago.
Several BlueZ-MCAP scripts are also avaiable; they were used mostly to test MCAP and CSP against PTS. It is not for normal consumption (thank God applications don't need to deal with MCAP directly!).
