On 29/07/2011 01:31, Brian Stansberry wrote:
Emanuel,
Or chat yesterday about the downsides of storing default values in the
in-memory management model got me thinking a bit.
Downsides:
1) The in-memory model no longer represents the user configuration
values; it also stores defaults. This is an issue when marshalling back
to xml; you either have to make the xml verbose by writing back all the
defaults, or you don't write back defaults and lose the fact the user
included the value in the original.
2) Possible versioning issues in a domain where different hosts run
different versions; i.e. if the version on the domain controller host
stores and pushes to servers a default value that a server running an
earlier version doesn't understand. This would really be a bug, since a
change in a default value should spur an increment in the subsystem's
schema and appropriate handling by the parser. But still, storing
defaults increases the chances of this kind of bug cropping up.
Possible solution:
What's been requested previously is that management clients be able to
see the default values, without having to go read the resource
description metadata to find them. That request can be satisfied via the
read-resource and read-attribute handlers. There is no need to store the
default in the model; those handlers can read the resource description
metadata to find the default if the model doesn't have a value stored.
That will slow those handlers down a little bit since the description
has to be generated and read, but those handlers aren't called as part
of our internal operations (e.g. boot) so doing it that way won't slow
down boot, deployment etc.
An issue that doing it this way raises is a client calling read-resource
or read-attribute doesn't know if the returned value is the actual user
config or is a default. A solution to that is to have those operations
accept a new parameter "defaults" which if false does not include the
defaults.
I'm not sure what the best default value for that "default" param would
be. My instinct is "true".
WDYT?
I personally wouldn't do this. I would leave the default out of the
read-resource etc result. That would keep things clear. When you obtain
the model you'll see that the value isn't specified. A management client
can easily also obtain the default from the description and nicely
present this to the user. The management client may actually want to
mark the default value as such for the users in a slightly different way
so having it come in somewhat separate can actually be helpful I think.
My 2c,
David