whitequark / rust-xdg

A library that makes it easy to follow the X Desktop Group specifications
https://wiki.freedesktop.org/www/Specifications/
Apache License 2.0
154 stars 30 forks source link

Relevant directory for user data? #8

Closed SimonSapin closed 8 years ago

SimonSapin commented 8 years ago

This question is not specific to the Rust implementation, but I couldn’t find an issue tracker for standards.freedesktop.org.

From the xdg::BaseDirectories doc-comment:

  • Configuration files store the application's settings and are often modified during runtime;
  • Data files store supplementary data, such as graphic assets, precomputed tables, documentation, or architecture-independent source code;
  • Cache files store non-essential, transient data that provides a runtime speedup;

Data files sound like what Servo calls "resource files": anything that should be shipped with the program, but not compiled into the main binary/executable. (This includes stylesheets, images, fonts, …) I don’t see the use for a user-specific directory for this category, but whatever.

What about user data such as browsing history and cookies? It’s more valuable than cache, it’s not really configuration/settings, and it’s not a "resource" shipped with the program. What directory do you think such data should go into?

whitequark commented 8 years ago

In practice, most applications that I use store such files in the data directory, i.e. ~/.local/share/; this seems to be the convention even if it's not in the spec.

Specifically Chromium, however, decides to effectively violate XDG and stores everything, even cache, in ~/.config/chromium, I suppose to make sandboxing easier by having all profile-related files under a single prefix.

whitequark commented 8 years ago

(Does Servo consider adopting rust-xdg? That would be neeeat)

SimonSapin commented 8 years ago

Servo doesn’t have any persistence right now but this might change soon, so I’m proposing using rust-xdg to decide where the files should go. http://www.mail-archive.com/dev-servo@lists.mozilla.org/msg01650.html

aneeshusa commented 8 years ago

@SimonSapin On Linux, the data you mentioned above (supplementary data, such as graphic assets, precomputed tables, ...), would go into folders specified by $XDG_DATA_DIRS, e.g. /usr/share. User-specific data (such as cookies) usually goes into the folder specified by $XDG_DATA_HOME, e.g. ~/.local/share.

Documentation and source code can go into $XDG_DATA_DIRS as well, but note there are special subfolders for man pages and GNU info pages; often other documentation formats are placed under a doc subfolder.

An application like Servo would generally make a servo subfolder in the above directories instead of using them directly. (However, note that man pages and GNU info pages have their own layout.)

SimonSapin commented 8 years ago

@aneeshusa So you’re saying that $XDG_DATA_DIRS and $XDG_DATA_HOME have a different use in practice (beyond system-wide v.s. per-user), despite the spec not making that distinction?

$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory.

Maybe this crate should reflect that practice? This would affect the find_data_file, list_data_files, and list_data_files_once methods which currently use both environment variables indiscriminately.

SimonSapin commented 8 years ago

Specifically:

How does this sound?

aneeshusa commented 8 years ago

Sorry, I was unclear. The only distinction is system-wide v.s. per-user, where anything in the user dir ($XDG_DATA_HOME) takes precedence over system dirs ($XDG_DATA_DIRS). However, things like graphics and precomputed tables are typically not overriden by the end user and can be safely shared system-wide, while there's no sensible default other than empty for user browser history or cookies. This leads to the de facto separation I mentioned.

I'll look more carefully at the crate but I don't think there's a need to change it; we should always lookup data (whether user-specific like cookies or more general like lookup-tables) via $XDG_DATA_HOME then $XDG_DATA_DIRS.

Excerpt from the spec:

 Other specifications may reference this specification by specifying the location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies that:

    Such file should be installed to $datadir/subdir/filename with $datadir defaulting to /usr/share.

    A user specific version of the data file may be created in $XDG_DATA_HOME/subdir/filename, taking into account the default value for $XDG_DATA_HOME if $XDG_DATA_HOME is not set.

    Lookups of the data file should search for ./subdir/filename relative to all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS . If an environment variable is either not set or empty, its default value as defined by this specification should be used instead. 
aneeshusa commented 8 years ago

I checked and the current code in the crate looks fine. Sorry for the confusion, I was thinking about packaging/installation locations for Servo's "resource files" in my earlier comment. The Servo code should be able to use rust-xdg without any worries, since we can just read the first data file found instead of needing any complex merging.

whitequark commented 8 years ago

Closing as @aneeshusa says the current behavior is fine. Feel free to reopen if that's not the case.