I guess I don't have a problem with merging them, although strictly
speaking they refer to different things - locks vs. the PINs needed to
unlock those locks.

Two other points to consider regarding lock/PIN handling in the new API:

   - PIN, PUK, PIN2, and PUK2 are PINs for SIM locks. The rest are device
   locks, so having them belong to the *.Sim interface doesn't seem completely
   right. But 3gpp gloms them all together, so maybe we should just live with
   this.
   - Shouldn't we add an argument to EnablePin and ChangePin that specifies
   the lock to which the operation should apply? This would mirror the CLCK
   and CPWD AT commands, which take the facility name as an argument. This
   would correct what seems to be an oversight in the current API.

Eric

On Wed, Nov 23, 2011 at 9:58 AM, Aleksander Morgado
<aleksan...@lanedo.com>wrote:

> Hey Eric & Dan,
>
> On Fri, 2011-11-11 at 15:10 -0500, Eric Shienbrood wrote:
> > Subject: [PATCH] Added new property to track which facility locks are
> > enabled.
> >
> > The property EnabledFacilityLocks on the .Modem.Gsm.Card interface
> > is a bit mask that indicates which of the various personalization
> > codes from 3GPP TS 22.022, plus the SIM PIN lock and SIM PIN2 lock,
> > are enabled. The set of facility locks supported by the modem is
> > determined at the time the modem is initialized, and the state of
> > each supported lock (enabled or disabled) is determined. When the
> > state of a lock changes, a property-change signal is sent out. Note
> > that ModemManager only supports enabling and disabling SIM-PIN, via
> > the EnablePin method on Modem.Gsm.Card.
>
> One of the changes I did in the new API was to have a new enum being
> reported in the "UnlockRequired" property instead of a string. I called
> this "MMModemLock", see:
>
> http://www.lanedo.com/~aleksander/modem-manager/api-20111123/mm-Flags-and-Enumerations.html#MMModemLock
>
> I also included your new MMModemGsmFacility enum in the new API, as
> well, named "MMModem3gppFacility":
>
> http://www.lanedo.com/~aleksander/modem-manager/api-20111123/mm-Flags-and-Enumerations.html#MMModem3gppFacility
>
> Any problem in merging these both types? It could be just making
> MMModemLock be a flags value instead of an enum. As far as I can see
> "MMModem3gppFacility" is a subset of "MMModemLock".
>
> Cheers,
>
> --
> Aleksander
>
>
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to