Re: Small nitpick about option names (was: RFC Debian package upgrade with Config::Model)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
On Tue, Jun 16, 2009 at 02:14:42PM +0200, Dominique Dumont wrote:
>Jonas Smedegaard <dr@jones.dk> writes:
>>>Quite good and closer to the current keywords. I'm quite fond of
>>>built_in though. May be "configfile_default" and "built_in_default" ?
>>
>> Would you mind the singleworded "builtin" instead? It seems cleaner
>> to me to have it <binding>_<type> with only a single underscore.
>
>I'm may be nitpicking, but what do you think of 'config_default'
>instead of 'configfile_default'? So we'd have 'config_default' vs
>'builtin_default'.
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
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.
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.
>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" defualts are really stored in another configfile
rather than actually being built into the binary itself.
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.
You could also call it "primary" and "secondary" - but wht is primary to
an administrator is secondary to a packager, and is second-and-a-half to
a blender that squeezes in later on.
In short, I strongly believe that it becomes a mess later, unless you
already now ontroduce awareness of a larger chain, and just label with a
"direction": did it come from upstream, or is it applied later for
downstream use.
Hope that made sense. It is slowly making sense to myself :-)
- Jonas
>[1] You can already see the presentation (in French)
> http://fpw2009.ubicast.eu/videos/free/64/
Sorry - I do not speak french :-(
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEAREDAAYFAko3pToACgkQn7DbMsAkQLjlEwCfYdoDwqfl4dDX1ffDa7/4vMqF
ovgAoKCaMgetdIEoiY285blrxOp82uPn
=lvtt
-----END PGP SIGNATURE-----
Reply to: