When we are done with a NMKeepAlive instance, we always should do
three things:
- unset the owner
- disarm (freeze) the keep-alive
- give up our reference.
Add and use nm_keep_alive_destroy() that does this.
set-forced is currently unused, so drop it.
NMKeepAlive in principle determines the alive-status based on multiple
aspects, that in combination render the instance alive or dead. These
aspects cooperate in a particular way.
By default, a keep-alive instance should be alive. If there are conditions
enabled that further determine the alive-state, then these conditions
cooperate in a particular way. As it was, the force-flag would just
overrule them all.
But is that useful? The nm_keep_alive_set_forced() API also means that only
one user caller can have control over the flag. Independent callers cannot
cooperate on setting the flag, because there is no reference-counting or
registered handles.
At least today, it's unclear whether this flag really should overrule all
other conditions and how this flag would actually be used. Drop it for
now.
NMKeepAlive is a full API independent of NMActiveConnection. For good
reasons:
- it moves complexity away from nm-active-connection.c
- in the future, we can use NMKeepAlive also for NMSettingsConnection
As such, the user should also directly interact with NMKeepAlive,
instead of going through NMActiveConnection. For that to work, it
must be possible to get the owner of the NMKeepAlive instance,
which is kept alive.
The names "floating" and "sink()" are well known and good.
However, "disarm()" seems the best name for the counterpart operation,
better than "float()", "unsink()", or "freeze()".
Since we have "nm_keep_alive_disarm()", for consitency rename
- "floating" -> (not) "armed"
- "sink()" -> "arm()"
All callers only want to create floating instances at first.
Also, it seems to make generally more sense this way: you create
a floating instance, set it up, and then arm it.
This simplifies nm_keep_alive_new(), which previously was adding
additional code that wasn't accessible via plain g_object_new().
The NMKeepAlive instance is useful to find out when we should disconnect.
The moment when we start disconnecting, we don't care about it anymore.
Add a nm_keep_alive_disarm() function to suppress property change events about
the alive state, after that point. Emitting further events from that point
on is only confusing.
Yes, this means, a NMKeepAlive instance shall not be re-used for
multiple purposes. Create a separate keep-alive instace for each target
that should be guarded.
Also, once disarmed, we can release all resources that the NMKeepAlive instance
was holding until now.
For P2P connections it makes sense to bind the connection to the status
of the operation that is being done. One example is that a wifi display
(miracast) P2P connection should be shut down when streaming fails for
some reason.
This new helper class allows binding a connection to the presence of a
DBus path meaning that it will be torn down if the process disappears.
