Skip to content
  • Lubomir Rintel's avatar
    libnm: use the o.fd.DBus.ObjectManager API for object management · 1f5b48a5
    Lubomir Rintel authored
    This speeds up the initial object tree load significantly. Also, it
    reduces the object management complexity by shifting the duties to
    GDBusObjectManager.
    
    The lifetime of all NMObjects is now managed by the NMClient via the
    object manager. The NMClient creates the NMObjects for GDBus objects,
    triggers the initialization and serves as an object registry (replaces
    the nm-cache).
    
    The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
    object creation, removal and property changes. It takes care of the
    property changes so that we don't have to and lets us always see a
    consistent object state.  Thus at the time we learn of a new object we
    already know its properties.
    
    The NMObject unfortunately can't be made synchronously initializable as
    the NMRemoteConnection's settings are not managed with standard
    o.fd.DBus Properties and ObjectManager APIs and thus are not known to
    the ObjectManager.  Thus most of the asynchronous object property
    changing code in nm-object.c is preserved. The objects notify the
    properties that reference them of their initialization in from their
    init_finish() methods, thus the asynchronously created objects are not
    allowed to fail creation (or the dependees would wait forever). Not a
    problem -- if a connection can't get its Settings, it's either invisible
    or being removed (presumably we'd learn of the removal from the object
    manager soon).
    
    The NMObjects can't be created by the object manager itself, since we
    can't determine the resulting object type in proxy_type() yet (we can't
    tell from the name and can't access the interface list). Therefore the
    GDBusObject is coupled with a NMObject later on.
    
    Lastly, now that all the objects are managed by the object manager, the
    NMRemoteSettings and NMManager go away when the daemon is stopped. The
    complexity of dealing with calls to NMClient that would require any of
    the resources that these objects manage (connection or device lists,
    etc.) had to be moved to NMClient. The bright side is that his allows
    for removal all of the daemon presence tracking from NMObject.
    1f5b48a5