Re: [Tracker] PATCH: Allow specifying user data & cache directory paths in DConf

[Jonatan Pålsson <jonatan palsson pelagicore com>]

Hi!

On 9 August 2013 16:29, Martyn Russell <martyn lanedo com> wrote:
> On 08/08/13 14:42, Jonatan Pålsson wrote:
> > Hi list,
>
>
> Hello Jonatan,
>
>
> > I would like to re-locate the user data directory and user cache.
> > Currently these directories are retrieved using g_get_user_data_dir ()
> > and g_get_user_cache_dir (), which in turn may be affected by the user
> > by setting appropriate XDG_* variables. I would however like a more
> > persistent setting, so I added the user-cache-dir and user-data-dir
> > keys to the org.freedesktop.Tracker.DB namespace in DConf.
> >
> > The behavior of the two keys is similar. If the key is set, it takes
> > precedence over g_get_user_*_dir () and the supplied path is used for
> > storing the files. If the key is empty (the default setting), the old
> > behavior is preserved.
> >
> > Please see the following patch:
> >
> > https://github.com/Pelagicore/tracker-ivi/commit/213456024d686305d0f6a30b09fa81f04e601fdd
> >
> > I also have a patch for setting the path to the ontology directory. I
> > will submit it in a different thread to keep the discussion separate.
>
>
> Can I ask why do you need this sort of patch?
>
> You can accomplish everything the patch achieves AFAICS by just setting the
> $XDG_CACHE_HOME, $XDG_CONFIG_HOME and $XDG_DATA_HOME environment variables
> before running any one of the Tracker binaries. In fact, this is what I do
> in the script I wrote to have localised Tracker DBs for different datasets.
>
> I would like to avoid adding more config and maintenance burden to specify
> locations. We already have a lot of that.
>
> Is there some reason the env vars are not enough?

Yes, the same functionality can be accomplished by using the
environment variables already in place. I think the configuration
options make it clearer for the user that these values can be changed
however. By having the options available in the config, they are
easier (in my opinion) to set for users. Previously, with the
environment variables, a wrapper script had to be written to
accomplish the same thing.

Ideally, I would like all available options not set at compile time to
be in the config. This would make the config a centralized place for
all configuration, and users could inspect it (and also get valuable
descriptions for each option if using a graphical configuration tool).
Settings can be exported using "dconf dump" and loaded using "dconf
load" - which would allow a user to save all settings and restore them
at a later point. This only makes sense if all settings are stored in
dconf however.

We probably have different visions for the config, mine is to make it
a central repo for *all* configuration. What is the official stance on
what goes in the config and what goes elsewhere?

Also, Philip: I have a new set of patches which should fix the issues
you showed. I will wait with submitting them until I know whether this
idea is at all interesting! :)

Thanks to both of you for reviewing the idea & patch!

-- 
Regards,
Jonatan Pålsson

Pelagicore AB
Ekelundsgatan 4, 6th floor, SE-411 18 Gothenburg, Sweden