These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
When a DBus error is received, the values of the other parameters
may be undefined, but bindings will assume they're valid and fail.
Capture this case and pass NULL to the callbacks.
Also, allow passing NULL instead of a callback, for bindings that
don't support the argument types.
Clients need to do their own logging using glib or whatever; these
macros while somewhat helpful were not flexible and are not a
substitute for actual logging in the client. g_warning, g_message,
and g_error are more suitable anyway.
DISCONNECTING: the only active network connection is now being disconnected
LOCAL, SITE, GLOBAL: one-stop items for level of connectivity, which
we'll use to show when we think we're actually connected to the internet
or behind a captive portal or something
sleep, wake, StateChange, all deprecated in 0.8, are now removed.
sleep & wake are replaced with the Sleep() method, while
StateChange is replaced with the StateChanged signal which has
the same arguments.
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.
