XDG Config Folders

[Martin Owens]

On Wed, 2010-09-01 at 00:19 +0200, Krzysztof Klimonda wrote:
> For example you are saying that emails should go to the directory
> specified in user-dirs.[defaults,dirs] but that makes no sense uless
> we
> are thinking about $DOCUMENTS/.email_app/. Emails, while being
> documents, aren't really suited for direct access. The same can be
> said
> for many other applications that doesn't fit into any of directory
> listed in the user-dirs.[defaults,dirs].

Direct access is a misdirection from the real problem of classification.
Sure emails shouldn't be just files and rarely would I expect a user to
use nautilus to manage their inbox, but the same can be said for most
data sets whether they be photo galleries (i.e. cheese) or emails.

What having them in user-dirs does is lay down a guarentee that the data
will be in a narrower set of standard formats and will make developers
think very carefully before they run away inventing new formats, new
indexing and new storage mechanisms.

Instead what it should promote is the sharing of data between
applications.

Of course few programmers really want to tie themselves down to using
standard formats in known locations with the possibility of having to
track externally modified data. It's still not a good excuse to hide
user data sets from both users and other developers.

Emails, events, bookmarks and contacts are user data sets just like
photos, documents and videos and it's a damn shame that we mis-classify
them and save their contents in strange places. But this is a gnome
problem and judging by that list of non-xdg projects to be converted it
looks like only a legion of developers all working on this full time
would be able to sort it out.

Anyone got a few million quid?

> XDG_DATA_HOKE is supposed to be basically a local, user-writable
> equivalent of /usr/share. There are many things that fit neither this
> requirement nor "user data" description. 

Yes, and anything else in the XDG_DATA_DIRS list. But few things don't
fit in my assessment of the problem. Perhaps we could do with a guide
and maybe I can have a word with a few pipe devels about their
experiences, requirements and thoughts on the whole thing of data
classification and storage.

Martin,