IMO point 2 can be neglected. It's an edge case, if you ask me.
The first point is no big deal. Verbosity or not. It's always better to strive for
a simple, easy to grasp solution. I believe (as a consumer of that API) that it should reflect the effective runtime model, no matter what. Including the defaults. Going through additional hoops & loops to figure out the effective runtime configuration is counter productive (curl,bash, etc) and will not be used.
Further more, consumer do not care if the attribute derives from a default value or not.
And why should they?
The fact that it's written back to xml, is an implementation detail to me.
But it should not mandate how the actually API works.
IkeOn Jul 29, 2011, at 2:31 AM, Brian Stansberry wrote:
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.