Support other Jeepney I/O options?

[takluyver]

At present, dbus_objects.integration.jeepney uses the jeepney 'blocking' I/O - which is suitable for a single thread, and nothing else can happen in that thread while it's serving requests.

One aim of Jeepney is to make it relatively easy (little extra code) to integrate with different I/O frameworks. Would you be interested in exploring how this would work in practice for dbus-objects?

In practical terms, all of the other I/O options (threading, asyncio, Trio) would let multiple tasks/threads handle requests on the same connection - although this only makes sense if the handlers do something slow which allows running another task while they wait. The asyncio & trio options can also integrate neatly into applications which use those frameworks.

[FFY00]

Yes, definitely. dbus-objects is written to be backend agnostic. The blocking factor right now is time.

I will probably work on adding support for signals and properties before I start adding more backend options, as I feel that is more relevant, but I am definitely happy to receive contributions 😊

[takluyver]

I can relate to being limited by time. :-) As and when I have some to spare, I might start investigating what this would take.

[FFY00]

I have refactored the decorator code, we now use object descriptors. I have only played with async a bit, so I am not too comfortable with it, but it looks to me like normal methods should already be compatible, as we never modify the object passed into the decorator, we just store it in the descriptor object. I think we should be able to just fetch the object and call it with async context in the dispatch backend.

The only place that needs to gain support for this is dbus_property, I think.