• Thomas Haller's avatar
    libnm: add generic-data for implementing NMSetting · 4e0f1b16
    Thomas Haller authored
    Add a new way how NMSetting subclasses can be implemented.
    Currently, most NMSetting implementations realize all their properties
    via GObject properties. That has some downsides:
     - the biggest one, is the large effort to add new properties.
       Most of them are implemented on a one-by-one basis and they come
       with additional API (like native getter functions).
       It makes it cumbersome to add more properties.
     - for certain properties, it's hard to encode them entirely in
       a GObject property. That results in unusable API like
       NM_SETTING_USER_DATA. These complex valued properties only
       exist, because we currently always need GObject properties
       to even implement simple functionality. For example,
       nm_setting_duplicate() is entirely implemented via
       nm_setting_enumerate_values(), which can only iterate
       GObject properies. There is no reason why this is necessary.
       Note also how nmcli badly handles bond options and VPN
       data. That is only a shortcoming of nmcli and wouldn't
       need to be that way. But it happend, because we didn't
       keep an open mind that settings might be more than just
       accessing GObject properties.
     - a major point of NMSetting is to convert to/from a GVariant
       from the D-Bus API. As NMSetting needs to squeeze all values
       into the static GObject structure, there is no place to
       encode invalid or unknown properties. Optimally,
       _nm_setting_new_from_dbus() does not loose any information
       and a subsequent _nm_setting_to_dbus() can restore the original
       variant. That is interesting, because we want that an older
       libnm client can talk to a newer NetworkManager version. The
       client needs to handle unknown properties gracefully to stay
       forward compatible. However, it also should not just drop the
       properties on the floor.
       Note however, optimally we want that nm_setting_verify() still
       can reject settings that have such unknown/invalid values. So,
       it should be possible to create an NMSetting instance without
       error or loosing information. But verify() should be usable to
       identify such settings as invalid.
    They also have a few upsides.
     - libnm is heavily oriented around GObject. So, we generate
       our nm-settings manual based on the gtk-doc. Note however,
       how we fail to generate a useful manual for bond.options.
       Also note, that there is no reason we couldn't generate
       great documentation, even if the properties are not GObject
     - GObject properties do give some functionality like meta-data,
       data binding and notification. However, the meta-data is not
       sufficient on its own. Note how keyfile and nmcli need extensive
       descriptor tables on top of GObject properties, to make this
       useful. Note how GObject notifications for NMSetting instances
       are usually not useful, aside for data binding like nmtui does.
    Also note how NMSettingBond already follows a different paradigm
    than using GObject properties. Nowdays, NMSettingBond is considered
    a mistake (related bug rh#1032808). Many ideas of NMSettingBond
    are flawed, like exposing an inferiour API that reduces everything
    to a string hash. Also, it only implemented the options hash inside
    NMSettingBond. That means, if we would consider this a good style,
    we would have to duplicate this approach in each new setting
    Add a new style to track data for NMSetting subclasses. It keeps
    an internal hash table with all GVariant properies. Also, the
    functionality is hooked into NMSetting base class, so all future
    subclasses that follow this way, can benefit from this. This approach
    has a few similiarties with NMSettingBond, but avoids its flaws.
    With this, we also no longer need GObject properties (if we would
    also implement generating useful documentation based on non-gkt-doc).
    They may be added as accessors if they are useful, but there is no
    need for them.
    Also, handling the properties as a hash of variants invites for a
    more generic approach when handling them. While we still could add
    accessors that operate on a one-by-one bases, this leads to a more
    generic usage where we apply common functionality to a set of properties.
    Also, this is for the moment entirely internal and an implementation
    detail. It's entirely up to the NMSetting subclass to make use of this
    new style. Also, there are little hooks for the subclass available.
    If they turn out to be necessary, they might be added. However, for
    the moment, the functionality is restricted to what is useful and
nm-setting-private.h 8.24 KB