> I was sort-of getting at this as a perfect example of a *property* on > the Interface object, not a method. The object should just have a > "MACAddressRandomization" property that you can use the standard D-Bus > Properties interface to get & set. We have a lot of those already. > > The downside of properties is that in some language bindings you cannot > receive errors from the Get & Set operations, but those language > bindings are kinda broken. I think a property sounds fine and am not worried about the bindings issue here. > So yes, while having these as method calls works, and (as I had > suggested) a single method call is perhaps less desirable, the best- > case for this is a property. Any time there's a get/set pattern, or an > enable/disable pattern, that begs for a property. This seems right, but I'm not sure how to make this understandable when the interface is going to have three states: disabled, default, and enabled with an explicitly specified mask. If the suggestion was not to have the user set a default but to have wpa_supplicant start up that way, then I'm not sure I want to do that because it will probably break any users who are using a MAC whitelist on their AP. I think it's best if this is disabled by default and users can turn it on from whatever UI they have. If the default is only meant for the initial setting, then having this as a property with len(mask) == 0 to disable and len(mask) == 6 to set the mask seems fine. Otherwise, if users can request the default mask through some other fashion, this might get messy. Thanks! -Eric _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
