Re: Changes to the proposed ModemManager DBus API

2011-10-01 Thread Aleksander Morgado

  Here is a set of changes to the proposed MM DBus API. Some of them were 
  already
  discussed some time ago in the following thread:
  https://mail.gnome.org/archives/networkmanager-list/2011-May/msg00162.html
  
  [PATCH 1/8] api: include ScanDevices() and SetLogging() in the new manager 
  API
  [PATCH 2/8] api: remove GetInfo() from the Modem API and use read-only 
  properties instead.
  [PATCH 3/8] api: let the Modem expose a 'Sim' property to link to a 
  specific SIM object
  [PATCH 4/8] api: let SignalQuality say if the given value was recently taken
  [PATCH 5/8] api: new SetAllowedModes() to be able to modify the allowed 
  mode in the modem
  [PATCH 6/8] api: new SetAllowedBands() to be able to modify the allowed 
  bands in the modem
  [PATCH 7/8] api: rename MM_MODEM_ALLOWED_MODE to MM_MODEM_MODE
 
 1 - 7 look fine to commit immediately.
 

Done.

-- 
Aleksander

___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property

2011-10-01 Thread Aleksander Morgado
Hey hey,

  Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE 
  values,
  and preference of a specific mode is now given in the new PreferredMode
  property and as an extra argument to the SetAllowedModes() call.
  
   * Supported Modes: bitmask specifying which modes are supported by the 
  specific
  hardware. For example, a modem may only support 1G/2G/3G connections (not 
  4G).
  
   * Allowed Modes: bitmask specifying which modes, of the ones Supported by 
  the
  modem, are allowed to use. For example, a modem may support 1G/2G/3G 
  connections
  but only 1G and 2G connections are allowed by the user as 3G involves more
  expensive data rates.
  
   [Allowed] ⊆ [Supported]
  
   * Preferred Mode: specific mode which is preferred among the ones defined 
  in
  the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G 
  connections
  but the user would like that if possible 2G be used, as 3G consumes too much
  battery. If 2G is not possible, 3G can be used.
  
   [Preferred] ∈ [Allowed]
 
 I don't have a huge objection to this, but I'm not sure I see the
 benefit of having the Preferred/Allowed split versus the complexity.
 Basically, if Allowed were an enum where we enumerated the preference
 there are 4 items to choose from (4G, 3G, 2G, empty) and 3 slots in the
 preference order (since empty doesn't get a slot, just a single enum).
 Thats a total of 25 combinations, but some like 2G4G don't really make
 sense, so we have somewhere under 25.  32-bits gives us a lot of range
 there if it's an enum not a bitfield.  The downside is that it has no
 relationship with the MM_MODEM_MODE flags.  My worry is just that it's
 added complexity (3 properties to check instead of 2) that may be just a
 bit more work for clients.
 

I do see problems in both implementations, and I understand that the new
one may be more complex, but trying to cope with the addition of 4G to
the list is not an easy task, I would say.

It would be good to check what modes the new LTE devices support. Is
there anyone out there who can check this? Do the devices support
specifying 'preferred' modes to automatically connect in one mode or
another?

Also, do the 4G devices support complex setups like 3G preferred, and
if not available go 4G or 3G preferred, and if not available go 2G.
As a user, I think I can find good reasons to need these last two
options, not just 3G preferred.

-- 
Aleksander

___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list