On 05/25/10 19:36, Shawn Walker wrote:
On 05/25/10 09:32 PM, Felix Feng wrote:
On 05/26/10 00:11, Antonello Cruz wrote:
Won't the users and installers have to change the null/empty value
with the value they want to configure the keyboard? How is that any
different than changing the value?
Yes, users only need to change the empty value to configure the keyboard
in empty value case. But if missing property is used, users need to add
a property including property name, property type and property value.
Users may not know the exact configuration name. And in empty value
case, kbd will be called to validate the value which users change. But
in missing property case, when users input a wrong property name, it's
not easy to validate it. Moreover, in empty case, if users want to know
which keyboard configurations they can change in system/keymap, they can
easily get the configuration list using svccfg or svcprop command. But
if missing property is used, system/keymap can not provide users such
list to instruct users to configure the keyboard.
Isn't a man page a more appropriate place to document the available
properties? Especially since I imagine many users will want a list of
what the valid values are for the property or an explanation of its
purposes.
Manpages and SMF templates are the right place for this. If you use
templates, higher level UIs will be able to use the templates to recommend
potential properties and values. I'd like to have svccfg do this in the
future more, but Visual Panels also consumes templates data.
Statements about validation for correctness are the same whether the base
manifest provides the defaults or not.
The SMF team is getting ready to file a case for the profiles used by
install that property types are optional in the profile if the value is
provided by the template data. So that's not a concern either.
But, you're getting very strong feedback from the SMF team and an ARC
member: don't use astrings when a more specific type is appropriate, which
it is here.
I'd also like to note that I'm more than a bit surprised that there isn't
a useful representation of the default configuration that could be used
aside from "uninitialized". Aren't there really *real* defaults for all
of these properties which could be used in the manifest? My first glance
through the property list suggests that there is. (e.g. keyclick is a
boolean with a default value of "false" in the manifest.) Why isn't that
being pursued directly? It would avoid this entire discussion about
uninitialized with the benefit of actually *showing* the administrator
what the defaults are.
liane
_______________________________________________
opensolaris-arc mailing list
[email protected]
