>>>> 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. > I started with enforcing read-only at the CLI, then came across the enforcement of automatic NCP in the library. I decided that making the CLI dumb and enforcing read-only (either when the property read-only is true or for the automatic NCP) at the library (also extended the opaque handle to include a read-only flag).
This requires that the library be able to distinguish calls from nwamd (which can override the automatic NCP read-onlyness). Some library functions have flags and can take the NWAM_FLAG_OKAY_TO_WRITE, but other functions can't (like set, create, etc) can't. I can go with enforcing read-only properties and read-only NCP's at the CLI level. In this case, should the library even have the OKAY_TO_WRITE flag? If this flag is around, it creates confusion as set, create, delete have to be enforced by consumers, but commit and destroy are enforced by the library. Either move all the enforcement to the library or to the consumer seems like cleaner solutions. I prefer the enforcement in the library, but will need to extend the API of the library (mainly nwam_ncu_create(), nwam_ncu_set_prop_value(), nwam_ncu_delete_prop()) to include flags (just like nwam_ncu_commit() and nwam_ncu_destroy()). Thanks, Anurag
