default profile directory

[paulrouget]

#10114 introduces a preference file.

The profiler directory is set via the --profile-dir option.

We should have a default directory.

This directory should not be created if it doesn't exist, but just if --profile-dir is not specified and default_profile_dir/prefs.json exists, then we should read this file.

I guess these are good-enough values:

• windows: %APPDATA%\servo\
• mac: ~/Library/Application Support/Servo/
• linux: use XDG Base Directory spec (or just ~/.config/servo/)

I would not be surprised if there was already a crate that resolves the default configuration directory for each platform.

[creativcoder]

I would like to work on it.

[paulrouget]

@creativcoder Sure! Let us know if you have any question.

[aneeshusa]

One of my long-standing irritations about Firefox is its lack of XDG Base Directory support. In particular, Firefox uses a single profile folder for all of its files, but the XDG spec has separate paths for configuration/preferences, caches, and data. I find this separation useful because it lets me use a git repo to keep my preferences synced, ignore the cache directory, and use regular backups to keep track of data. I would really appreciate it if we could support this separation in Servo and use separate folders; placing the entire profile folder under ~/.config/servo breaks this contract.

Because we're starting fresh here, I'd appreciate getting this right from the start; it's much harder to change the default directory once something has been hardcoded and there is a significant user base already using the old directories. For example, Atom released their 1.0 without addressing this and is now locked into their current defaults.

I'm not sure what similar norms exist for Windows and OS X, but we should make sure to follow them.

[creativcoder]

@aneeshusa Ok. Looks like we have a library already that follows XDG base directory spec https://github.com/whitequark/rust-xdg . We can use that. Will need @paulrouget suggestions on this.

[paulrouget]

@SimonSapin Wanna chime in? I've seen you commented there: whitequark/rust-xdg#8

[SimonSapin]

I agree that we should separate non-essential / cache files from configuration / preferences and user data. The conventional way to do that on Linux is per XDG, but I don’t know about other systems. I’d be in favor of putting that separation in place even if we only have preferences so far.

Unfortunately that makes a nice single --profile-dir command-line option not enough. I don’t have a good answer there.

The rust-xdg crate looks good. We may want to make another crate that abstracts different platform’s conventions (using rust-xdg on #[cfg(all(unix, not(target_os = "macos"), not(target_os = "ios")))])

[aneeshusa]

Thanks for listening, this is a small thing that makes a big usability difference for me. :)

XDG specifies a set of environment variables that allow overriding the folders used for config/cache/data separately; it looks like the rust-xdg crate already uses these.

As far as command line options, I think a --config-dir option may be useful; I don't think I've ever used a --cache-dir or --data-dir option before. (Some applications also 'bootstrap' by making cache and data directory configuration settings, so you can control everything via one option.)

[SimonSapin]

(Some applications also 'bootstrap' by making cache and data directory configuration settings, so you can control everything via one option.)

Sounds good to me.

[creativcoder]

@SimonSapin
So i went through the relevant code, and am thinking of something like this.
Tell me if this is the way to go.

First we'll add an extra field config-dir to Opts struct, then
within default_opts() method on initializing the config-dir field, we will call something like : xdg::get_default_config_dirs()

We can create a mod xdg.rs under util, which will contain #[cfg(target_os="")]
conditional method namd get_default_config_dirs(), and when platform is linux, that method, will
initialize directories according to XDG spec, but for other platforms it will return directory strings
what @paulrouget suggests.

[SimonSapin]

Sounds good, except we should have a thing (module, crate, …) to abstract platform differences called something like "basedirs" but not "xdg", since XDG is only relevant and xdg-rs is only used on some platforms.

[creativcoder]

@SimonSapin @paulrouget Hi have a look at basedirs module; tell me if this looks good, or suggest if this can be done better. https://gist.github.com/creativcoder/7f4a3b57c2c3dc08da47f26a15db7298

[SimonSapin]

@creativcoder These functions should return Option<PathBuf> rather than Option<String>. And to leave room for multiple profiles they should add a servo/default suffix rather than just servo. Looks good other than these details, thanks for pushing on this front!

[aneeshusa]

rust-xdg actually has profiles built in; just replace calls to with_prefix with with_profile and use default for the profile parameter.