We won't allow changing modes or bands through Simple.Connect(). Applications
should instead look at the corresponding SupportedBands or SupportedModes, and
then use SetCurrentBands() or SetCurrentModes() explicitly.
And also make it a list of masks, specifying which are the specific combinations
supported, not just one mask with all.
E.g.:
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7710'
| revision: 'SWI9200X_03.05.19.04ap r5475 carmd-en-10527 2012/09/17 17:57:14'
| supported: 'gsm-umts
| gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '358178040668164'
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
We want to expose in the Modem interface the list of supported IP families, and
the easiest way to do so is to have the IP family as flags, and provide in the
interface a single enum.
Also, a value of 0 for a MMBearerIpFamily specifies that no flags are set, so
just rename it to 'NONE'.
And add a new 'ANY' value which sets all flags to 1.
We cannot g_array_unref() the GArray when get()-ing bands as that will clear
the contents of the GArray, even if there are references around. Instead, just
dup the array contents when returning.
This patch adds a 'bearer-default-ip-family' property to MMBearer, which
specifies the default IP family to use for a bearer when no explicit
value is given via the simple connect properties. The default IP family
is set to IPv4 in MMBearer but can be overridden by a MMBearer subclass,
which allows a modem plugin to specify an appropriate default value.
We don't want to support only 'relative' validity, so don't assume that the
Validity property will always be a uint32 value.
Instead, we define the Validity propery as '(uv)' tuple, where the first value
(a MMSmsValidityType) specifies the type of validity, and the second value is
a variant formatted accordingly to what the validity type specifies (e.g. a
uint32 value if the type is MM_SMS_VALIDITY_TYPE_RELATIVE).
A 'GDBusObjectManagerClient' for a service for which there is no current
name-owner is a perfectly valid and useful object. For example, we could then
connect to the 'notify::name-owner' property to follow the life cycle of the
ModemManager process.
So, don't tie the successful creation of a 'MMManager' to the successful
creation of the internal GDBusProxy for the 'Manager1' interface. If there is
no current name owner, the GDBusProxy wouldn't be created, and instead we
would completely fail the 'MMManager' creation.
In order to have a proper conversion between DBus error names and GErrors for
our known domains, the associations need to be registered before any DBus
call attempt.
Given that the high-level API of libmm-glib has its entry point always in the
MMManager, just register them as soon as the first such object is created.
We do need to specify which is the primary port being used for controlling the
modem. This allows us to match the device with an already existing bluetooth
device in NetworkManager.
Specifying 'none' is really not exclusive. We may want to say that the modem can
either authenticate with a given protocol, or otherwise just try without
authentication.
The reality is that 'none' itself is usually always given in the connection
settings.
For bearers using STATIC or DHCP IP method, the modem itself is the one
negotiating authentication with the network. The new `allowed-auth' property
allows users to specify which authentication method(s) are allowed to be used.
See the following NetworkManager commit for more reference:
commit 34aef8aaaa09b7473b9496aa49e550bd2def03f8
Author: Andrew Bird <ajb@spheresystems.co.uk>
Date: Thu Mar 15 16:19:43 2012 -0500
Aleksander Morgado
Dan Williams
Yunlian Jiang
Ben Chan
Colin Walters