search

FFY00 / dbus-objects

DBus objects implementation on top of the Python type system
https://dbus-objects.readthedocs.io/en/latest/
MIT License
11 stars 4 forks source link

Support server/peer-to-peer mode #36

Open amezin opened 3 years ago

amezin commented 3 years ago

See https://developer.gnome.org/gio/stable/GDBusServer.html

Processes can use D-Bus protocol to talk directly to each other, without a bus.

But in the current code DBusServerBase's __init__ (and then all of its subclasses) has "bus type" and "name" parameters that both don't exist in server/peer-to-peer mode.

FFY00 commented 3 years ago

Does jeepney support this? I don't think so, right?

The bus argument should be made optional and keyword-only, and then we add whatever arguments we need to support peer-to-peer mode.

amezin commented 3 years ago

Does jeepney support this? I don't think so, right?

No, it does. At least, from the code it looks so.

class DBusConnection:
...
    def __init__(self, reader: asyncio.StreamReader, writer: asyncio.StreamWriter)

jeepney's asyncio.DBusConnection can be created from an arbitrary reader/writer pair (and, luckily, it also skips typical bus connection steps). So I can create it from any socket/pipe I want.

What's the point of storing bus and name?

By the way, acquiring a (well-known) bus name isn't necessary for exporting objects, even when connecting to a bus (they will be available under connection's unique name).