Skip to content

How to create two (or more) interfaces with the same name #103

Open

Description

@arkq

I have a case where I have to create two interfaces with the same name, but with different properties (these interfaces are exposed on different paths). Basically I have two options: a) create one class which will return properties based on exposed path (some props are optional) b) create two classes with the same interface name. Unfortunately, both these solutions are not possible right now.

In case of option a) the limitation seems to be imposed by libsystemd. It's not possible to define property as "optional", i.e. when property is not available, the org.freedesktop.DBus.Properties.GetAll does not return value for such property and org.freedesktop.DBus.Properties.Get returns org.freedesktop.DBus.Error.InvalidArgs: No such property 'Name'. The problem is that the sd_bus_emit_interfaces_added_strv() function collects all properties internally and in case when property value getter fails, the entire sd_bus_emit_interfaces_ added_* call fails. There are some possibilities like libsystemd-specific PropertyExplicitFlag flag, but this conflicts with PropertyEmitsChangeFlag. So, such approach is not ideal.

For option b) the problem is with sdbus internals where parse_properties_changed uses global DBUS_INTERFACE_NAME_TO_CLASS mapping... Would it be possible to remove internal mapping in favor of user provided list of interfaces? This function takes interface argument but does not use it...

Activity

  1. igo95862 commented on Apr 15, 2025

    @igo95862
    Collaborator

    Hello @arkq

    For option b) the problem is with sdbus internals where parse_properties_changed uses global DBUS_INTERFACE_NAME_TO_CLASS mapping... Would it be possible to remove internal mapping in favor of user provided list of interfaces? This function takes interface argument but does not use it...

    There is an alternative implementation idea I had on how to store the interface metadata without global variables but I really don't want users to create same interface names with different implementations. Maybe I should make it emit a large warning instead of completely preventing it. Seems like a lot of legacy code likes to have duplicated interface names.

  2. igo95862 commented on Apr 16, 2025

    @igo95862
    Collaborator

    In case of option a) the limitation seems to be imposed by libsystemd. It's not possible to define property as "optional", i.e. when property is not available, the org.freedesktop.DBus.Properties.GetAll does not return value for such property and org.freedesktop.DBus.Properties.Get returns org.freedesktop.DBus.Error.InvalidArgs: No such property 'Name'. The problem is that the sd_bus_emit_interfaces_added_strv() function collects all properties internally and in case when property value getter fails, the entire sd_bus_emit_interfaces_ added_* call fails. There are some possibilities like libsystemd-specific PropertyExplicitFlag flag, but this conflicts with PropertyEmitsChangeFlag. So, such approach is not ideal.

    The vtables can't really be modified once created but sd-bus also supports fully callback based objects. (see sd_bus_add_object) The obvious downside that you will have to re-implement the entire properties, ping and other logic that vtable automatically provides.

  3. arkq commented on Apr 16, 2025

    @arkq
    ContributorAuthor

    I agree that everything here is a workaround for something else. IMHO, the proper solution for a) would be a logic within libsystemd which will allow skipping adding property to the InterfacesAdded when getter returns some value indicating that the value is not available right now. However, it looks that the optional property "feature" is not something that D-Bus specification covers... so I'm not blaming libsystemd that it lacks such functionality.

  4. igo95862 commented on Apr 16, 2025

    @igo95862
    Collaborator

    Do you want to open systemd issue about it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions