Do you really need that exe helper ?

[benallard]

Can't ctypes do the job as well ? It would really be a big improvement I think.

[IanHarvey]

If BlueZ provided a .so file with functions I could call, ctypes would be the way to do it. Sadly, it doesn't - things like 'gatttool' are made from a whole load of source files compiled into a monolithic executable. It's difficult to even make this into a useful library because it's based around a GLib 'GMainLoop', which sends callbacks to various handlers when things happen on the Bluetooth socket. For these to work, g_main_loop_run() has to be running continuously, which makes it hard to run Python at the same time...

So, ideally, I might write a pure-Python implementation which talks directly to the kernel on a Bluetooth socket, but that a lot of code to rewrite.

[benallard]

Thank you very much for the detailed explanation.

I believe the answer might be through the development of an API in close
collaboration with the Bluez project ... Splitting their gattool into
library + exe. Probably something like a btle_initialize() and
btle_finalize() to start and stop the event loop in a separate thread will
have to be introduced in such an API. Or, as you mentioned, a complete
reimplementation of their stuff in pure python. But I wouldn't go down that
road unless the first one looks very ambushed. Let me know if you make some
progress the one way or the other !

On Thu, Mar 13, 2014 at 8:42 AM, Ian Harvey notifications@github.comwrote:

If BlueZ provided a .so file with functions I could call, ctypes would be
the way to do it. Sadly, it doesn't - things like 'gatttool' are made from
a whole load of source files compiled into a monolithic executable. It's
difficult to even make this into a useful library because it's based around
a GLib 'GMainLoop', which sends callbacks to various handlers when things
happen on the Bluetooth socket. For these to work, g_main_loop_run() has to
be running continuously, which makes it hard to run Python at the same
time...

So, ideally, I might write a pure-Python implementation which talks
directly to the kernel on a Bluetooth socket, but that a lot of code to
rewrite.

Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-37506991
.

[ryanleary]

This is what bluepy should really be doing, IMO. I started a branch a while ago (I'll have to dig it out--it's on another machine) that moves toward making a bluepy shared library. From there, you could create a C application for command-line experimentation (like currently), and direct python support via https://docs.python.org/2/extending/extending.html

[kalfa]

@ryaneleary can you expand a bit what you are doing?
I'm in the (slow) process of refactoring bluepy to have it work in a generic async environment (tornado, twisted, asyncio, etc). Do you think what you are doing is going to help in this direction as well?

[ryanleary]

By making a bluepy shared object library, you could create a native python module (a la https://docs.python.org/2/extending/extending.html). This would avoid the pipe-based inter-process communication that bluepy requires currently.

[xrmx]

Why not using the dbus api instead of poking with C code? See api docs (*-api.txt) here https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc

[IanHarvey]

The dbus API post-dates the original bluepy work, it wasn't available when I started. Also, it's still labelled 'experimental'.

I'm closing this issue now; of all the things I might do with bluepy, rewriting existing functionality is a very low priority.

Thanks
Ian