Hi! On 12 August 2013 11:08, Martyn Russell <mar...@lanedo.com> wrote: > On 12/08/13 07:43, Jonatan Pålsson wrote: >> >> Hi! >> >> On 9 August 2013 16:29, Martyn Russell <mar...@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 > > > The user shouldn't be changing these sort of things though. > This is really an option for packagers and people who are integrating > Tracker into their environment. > > >> 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. > > > I guess that depends how launch things. > > If the environment is set in your ~/.bashrc (for example), then there is no > wrapper script needed). > > It sounds like you need a unique solution here for "a" user, not all users. > Consider that adding an option like this and setting up the config per user > is much more involved than using a wrapper script or the correct .bashrc / > skeleton. > > >> Ideally, I would like all available options not set at compile time to > > > This isn't a compile-time thing. It's a run-time thing. >
Yes, poor choice of words from my side. I would like all values, which are not decided on compile time, to be in the config. > >> 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. > > > Do you have a real use case for this? > Most users, in fact, I would wager a great deal of them don't know where the > databases are or really care. Again, I see this more as a packaging / > systems integrator issue than a user issue - and the config is primarily for > user configurable options. > Yes, this is probably the core issue. I view the config as a general purpose store for configuration options. I understand the opposition for these sorts of changes if this is not correct usage of the config in Tracker. > >> 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? > > > There is no official stance really. > > With each configuration option you add maintenance burden. If users aren't > interested in changing an option we generally remove it. We do use > environment variables to override a lot of stuff, see: > > > https://developer.gnome.org/libtracker-sparql/unstable/tracker-overview-environment-variables.html > > These are not what we would generally expect a user to be playing with > though. They are more debugging / operational changes which systems > architects may choose to use for whatever integration purposes they're > considering. > > >> 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! :) > > > Which issues? > There were quality issues with the patches I submitted, the new patches are on the usual GitHub. Thanks for discussing the placement of configuration options, it is very interesting. I can see the point of separating integrator / user options in different "systems" (env. variables / dconf), since this allows Tracker to make it harder for users to change sensitive options. I don't have any argument other than that it would be nice to centralize all config options. I still think this would be nice, but I won't submit more patches of this sort ;-) > >> Thanks to both of you for reviewing the idea & patch! > > > Thanks Jonatan ;) > > > -- > Regards, > Martyn > > Founder & Director @ Lanedo GmbH. > http://www.linkedin.com/in/martynrussell -- Regards, Jonatan Pålsson Pelagicore AB Ekelundsgatan 4, 6th floor, SE-411 18 Gothenburg, Sweden _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
