Howdy, I cleaned up some of the dbus changes I needed for bewest#1, https://github.com/bewest/openxshareble.

In particular, I found the UART class and examples very very helpful, thanks!
Has anyone thought about releasing it through pypi so projects can use a package manager to install the python lib?

LGTM

Aside, there's some useful stuff in #7, I'm wondering if we can maybe sync up.

Aside, dbus-python is older, pydbus is the newer thing
Since dbus-python, pydbus has come around to replace dbus-python with gdbus based backend via gi.repository goodness. I've highlighted a number of issues which have all been solved as of glib 2.45.

For posterity:

• https://bugzilla.gnome.org/show_bug.cgi?id=656330
• Naive attempt (missing an extra loop/threading thing ) xxx: hangs on first Event.wait bewest/Adafruit_Python_BluefruitLE#3
• https://gist.github.com/bossjones/e054e224f5b8578dff0a#gistcomment-1710180
• dbus.service.Object alternative LEW21/pydbus#7

The updates in glib 2.45 are really only needed in the scenario where someone needs to export services on dbus by using ble. In scenarios like this, the older dbus-python api has a problem where nested mainloops "coalesce" causing the event listeners to be duplicated.

I've spent several weeks evaluating pydbus, which really needs glib 2.45 to work, vs txdbus, versus the limitations of the older API. The older API can be worked around in my scenario by promoting variety of "background threads" to full blown processes, all using the older API. However, it's not really open to new features or patches (eg to workaround properties), and pydbus is, pending glib 2.45 becoming more widely available.

I took a very brief stab at duplicating a lot of things to adapt the pydbus methods with minimal changes. One big change I mad was eliminating the dbus-pythhon's DBusGMainLoop, which naturally causes the first call to Event.wait to hang. I've read in various places about either iterating the mainloop and the threading docs, as well as techniques using generators, but not quite sure how to proceed with "minimal changes" versus what redesigns using a pure pydbus API might be desired (for client, at least until glib 2.45 is widespread)?

Sad attempt: bewest#3

• - Is it worth doing a txdbus provider? It would be based on twisted reactor instead.
• - Is Gio.Application somehow usable instead of Gtk.Application?? A lot of IOT apps don't need GUI! The reason we're exporting over dbus/BLE is to provide other apps for opportunity to provide a slick GUI.

P.P.S., again for posterity
My use case is https://github.com/openaps/oacids, openaps/openaps#80, https://github.com/bewest/openxshareble. What happens when I run python -m oacids.tools.do monitor-cgm monitor-cgm, I see the Dexcom, BLE's "heartbeat" characteristic's notification duplicate each run. Careful analysis of the source indicates a static global in dbus-python as the cause. The problem should be solved by gdbus' ability to hop contexts if needed. I realize few people have access to this device, so advice on constructing a simple, hello-world test case, simulator would be more than welcome! What the above command intends to say is: "run monitor-cgm twice in a row". Monitor-cgm uses ble to obtain a uart-like connection over ble to a device, setup some listeners to it's heartbeat characteristics, rx and tx characteristics for the UART adapter, and then executes a few logical UART commands. When this runs daemonized overnight, dbus eventually errors because we've been asking for duplicate events listeners.

Is this something that can be merged? Or do we need to create a fork over at https://github.com/openaps/ for ongoing openxshareble support?

@adafruit can you tell us if this library is still updated, or we should fork it and maintain it. It's used as part of openaps. We need these patches and donatieng@af46b05

forking is best!

This library has been deprecated. Please update to use this new library:
https://github.com/adafruit/Adafruit_Blinka_bleio
PR's can be submitted to the new library.