Don't delete them if we don't have permission for them, since
we may get permission for them later via Update. But to listen
for Update we need the connection around.
When the connection becomes invisible to a user (ie, the permissions
of the connection no longer allow that user to view the connection)
then we have to hid the connection from clients. But we can't
just dispose of it, because visibility changes are signaled with
Update signals on the connection itself, and thus we need to keep
the connection around just in case it becomes visible to the user
again. But if it's invisible, make sure we clear out the settings
since they may have changed.
This policy will allow users to modify their personal connections (ie
maybe VPN connections, etc) distinctly from system-wide connections that
affect more than just their user. It makes sense to be more lenient when
making changes to settings that don't affect other users.
Meaning stays the same, but this will allow us to differentiate
in the future between personal connections (ie, just visible to
one user) and system connections (visible to more than one user).
Simplifies code internally, and makes it easier for clients as well in
some cases where they want to control what ends up in the resulting
hash and what does not.
The Settings.Connection interface is now only provided by NetworkManager
itself since there is only one settings service. NM can validate
requests for secrets internally and thus there's no need to lock down
GetSecrets using a separate D-Bus interface, since PolicyKit provides
that functionality on systems where this is desirable (ie multi-user).
Single-user systems that do not have PolicyKit will inherently trust
the user already, or if not D-Bus auth is flexible enough to lock
down the GetSecrets method individually even if it's not on a separate
D-Bus interface.
Second, since only clients like connection editors or applets will be
calling the GetSecrets method, there's no need for 'hints' or
'request_new' arguments here since this method should never trigger
an interactive secrets request. Only NM should send those requests
when it knows it needs to ask the user, either during connection or
after validating the incoming GetSecrets request. A connection editor
type application should never be able to trigger the normal
"What's your passphrase" dialog thats provided by the secret agent
for that user's session.
Add the necessary annotations (the mininum required, that is those
on return values. NULL parameters or container types may require
more), and the Autotools stuff to get a NetworkManager GIR for
libnm-util and a NMClient for libnm-glib.
First, remove anything dbus-glib related from the public API and use
callbacks to handle returning secrets requested by D-Bus. Second,
add helper functions so local code can use the same API to request
secrets.
Heavily modify Inaky's Intel WiMAX SDK glue (originally from connman)
to be more generic and more thread-safe, and suitable for use with
NetworkManager instead of rolling our own client code. Rewrite the
NMDeviceWimax code to mostly work.
Still to be done: actual connection logic, DHCP handling, spawning
wimaxd if it's not started yet
