Convention Over Configuration: A Way Forward?

[Kevin Krammer]

On Monday, 2012-01-09, Thiago Macieira wrote:
> On Sunday, 8 de January de 2012 17.49.12, Trans wrote:
> > I mean that they don't use the environment variables.
> 
> I really don't think the environment variables are an issue.
> 
> As Kevin said:
> > > Hmm. I haven't done any application with just low level APIs but
> > > reading an
> > > environment variable and a string comparison seems indeed rather
> > > trivial to
> > > me. Though I can only speak for languages I've used so far, e.g.C/C++,
> > > Java,
> > > Python. Might be more complicated elsewhere.
> 
> Getting the value of an environment variable and applying a default if it's
> not set is the least of the issues. They *already* have to do that for
> $HOME if they want to save their configuration files in the home
> directory, with fallback to values read from the password database.

Right, I didn't consider that they already have to read an environment 
variable.
But maybe they consider $HOME to be always set or only explicitly unset, i.e. 
always just do
config_path = getenv( "HOME" ) + config_name

If that would be the case specifying XDG_*_HOME should be always set would 
help then.

> For that reason, I don't think you're addressing the source of the problem.
> It's more likely that they don't know that the option exists in the first
> place, that they are lazy to change their code, or they simply don't want
> to change from old Unix convention. Neither of those problems will be
> solved by hardcoding the path to $HOME/.config.

My theory as well. Hence my original question on whether there is any evidence 
to the contrary.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20120109/57049693/attachment.pgp>