On Tue, 06 Jan 2009 16:22:13 +0000
Alan Maguire <Alan.Maguire at Sun.COM> wrote:
> Anurag S. Maskey wrote:
> > Anurag S. Maskey wrote:
[...]
> >> By extension, the flags would be added to the respective enm, loc, and
> >> wlan functions also. (BTW, should nwamd be able to override the
> >> read-only property of these objects?)
[...]
> This all feels quite complex to me. If I remember
> correctly, the issue is that as a matter of policy we
> wish to preclude the UIs (nwamcfg and the GUI) from
> changing to the automatic NCP. My argument was
> that although we could potentially solve this policy
> issue in one place (in the library), that it might instead
> make sense to have logic in both nwamcfg and the
> GUI to preclude this (e.g. "if NCP == automatic setprop
> should fail", or "if NCP == automatic gray out text").
> I understand that architecturally it seems better to solve
> this in one place - the library - but given that there's only
> one object (the automatic NCP) that we want to make
> read-only, the approach of changing the library like this
> seems like a lot of work. It also feels a bit confusing having
> a readonly property that we sometimes ignore with
> an OKAY_TO_WRITE property, at least to me. Thanks!
The two different methods don't seem that different in complexity to
me. Either you spread it around a bit or you centralize it a bit.
Given the potential value of having a read only attribute commonly
applied to different objects and the fairly easy conceptual nature of a
"force flag" I slightly favor the attribute implementation method.
That is slight enough I think Anurag should pick which ever method
makes the most sense to him as the implementer.
mph
