Re: Small nitpick about option names
Jonas Smedegaard <dr@jones.dk> writes:
> Please reread my earlier post about this. My main point, contained in
> multiple sentences, slowly vapouriced as the sentences were quotes
> separately.
>
> They both hold configuration values, and both are defaults. The
> difference is to *whom* they are defaults:
>
> author → packager → blender → installer → administrator → user
ah .. I'm now understand why we don't seem to hear each other ;-)
Let's step back a little to better explain what's currently available in
Config::Model.
Currently the main purpose of distinguishing between 'builtin_default'
and 'config_default' is to avoid cluttering the configuration file.
>From an end user point of view, (i.e. on the Perl/Tk GUI),
'builtin_default' and 'config_default' are blended [1] and shown as
'standard value'. The user only see a green arrow on the interface if
the value was customised. I doubt that a casual user will care if the
standard value seen in the interface was decided by author packager,
blender or whomever.
The main (and currently only) purpose of 'builtin_default'
and 'config_default' parameters is to:
- write a parameter in the config file if the value is tagged as
'custom' or 'config_default' (slightly simplified to keep this mail
short)
- *not* to write a parameter in the config file if the value held in the
tree is identical to the 'builtin_default'
This strategy avoids cluttering the written configuration file. For
instance, without this distinction, sshd_config written by config-edit
would always have more than 50 lines.
For what it's worth, the current levels of "defaultness" implemented in
Config::Model (albeit with dubious names) are documented in [2].
With the current implementation, the decisions taken in the "derivation
chain" you mention can be implemented this way:
- author => builtin_default specified in model
- packager, blender => config[file]_default specified in model
- installer, administrator => preset value stored not in the model but
in the configuration tree
- user => customized value stored in the configuration tree
For instance, by default, sshd authorize root to log in. So Sshd
model[3] specifies 'builtin_default' as 'yes',
Debian, on the other hand specifies that PermitRootLogin should be
'no'. So Debian packager should patch (with patch) Sshd model like to
add 'config_default' => 'no'. Blender's role and action could be
similar.
Here's another example that show how preset value can be used. When
config-edit-ssh [4] is invoked by non-root user:
- config-edit-ssh loads /etc/ssh/ssh_config in configuration tree as
preset mode
- Preset values are shown as 'standard' value in the GUI
- user's values are highlighted by a green arrow only if they are
different from 'standard' value (i.e. preset//default//builtin in Perl
5.10 notation)
> A builtin value is provided by author as default for its downstream
> (which, when packaged, becomes the packager only)
>
> A config default might be provided by various parts of the chain, e.g.
> by packager when found in /etc/<package>/<package>.conf and by
> administrator when found in /etc/skel/.<package>rc - or for another
> structure by administrator in /usr/share/<package>/<package>.conf and by
> administrator in /etc/<package>/<package>.conf.
>
> You mentioned at some point that properly reflecting this chain of
> derivation would be more work.
Depending on how we want to track it, yes.
I can see 3 ways to handle this derivation chain:
- the derivation chains simply patches (with diff and patch) the
upstream model (which is possible with current implementation)
- the derivation chains updates the model with config-edit-model (with
diff and patch) the upstream model (also possible with current
implementation). The resulting model does not keep track which part
comes from packager or blender.
- config-model is modified to track who sets which default value (here
more work is required to come up with a pragmatic mechanism, taken
into account the 2 different modes: model update or config tree
update)
sol. 1 is very simple
sol. 2 is a little bit more complex but will be more resilient to
upstream model changes
sol. 3 will be tricky to set up and tough to explain
The more I think about, the more I;m convinced that sol. 3 is not good.
> I suggest using names related to the chain. Generic ones for now, and
> when the underlying code becomes more flexible, specific names can
> perhaps be used.
>
> With that in mind, I concretely suggest to use the terms
> upstream_default and downstream_default.
Let's nail down the question above before discussing options names
>>After all, Config::Model could be used to configure directly an
>>application instead of using a configuration file. That's just a matter
>>of setting up a backend with IPC.
>
> Yes. But that goes for builtin_default too, doesn't it? It might be
> that the "builtin" defaults are really stored in another configfile
> rather than actually being built into the binary itself.
yes, but this would be handled by the application, thus hidden from
config-model.
> I believe that Config::Model really do not care if it is builtin or not.
> What matters is that one came first, with the other being optional. One
> functions as "fallback" and the other as "override". But using the
> _feature_ to label the variable makes it confusing later to expand to
> support a wider chain, I fear: Same part of the chain has both
> "fallback" and "override" feature, depending on context.
If I read you correctly, you favor, like me, a simple solution: patch
the model along the derivation chain. Am I right ?
> Hope that made sense. It is slowly making sense to myself :-)
And I'm slowly finding better ways to explain what I have in mind :-)
I hope the explanations I gave above are enough to better understand
what's going on with Confi:Model.
If not, consiredering that:
- this thread is already too long
- the 2 of us are probably the only ones still reading it ;-)
I suggest that we talk this through over the phone (I'll send you in a
private mail my phone number)
Then, we will be able to nail down the option names.
> Sorry - I do not speak french :-(
No problem. I don't speak Danish either ;-). I guess I'll have to find
an english speaking conference sooner or later to present Config::Model...
All the best
[1] standard value is computed from builtin_default config_default and
some other stuff, for details, see
http://search.cpan.org/dist/Config-Model/lib/Config/Model/Value.pm#fetch_standard
[2] http://search.cpan.org/dist/Config-Model/lib/Config/Model/Value.pm#Default_values
[3]
http://cpansearch.perl.org/src/DDUMONT/Config-Model-OpenSsh-1.205/lib/Config/Model/models/Sshd.pl
[4] http://search.cpan.org/dist/Config-Model-OpenSsh/config-edit-ssh
--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner
irc:
domidumont at irc.freenode.net
ddumont at irc.debian.org
Reply to: