From: David Bremner <david@tethera.net>
To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org
Subject: Re: [PATCH 6/6] WIP: support XDG database directory
In-Reply-To: <m2k2l56iiu.fsf@guru.guru-group.fi>
References: <1453561198-2893-1-git-send-email-david@tethera.net>
 <1457785890-17058-1-git-send-email-david@tethera.net>
 <1457785890-17058-7-git-send-email-david@tethera.net>
 <m2k2l56iiu.fsf@guru.guru-group.fi>
User-Agent: Notmuch/0.21+74~g6c60fb1 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Sat, 19 Mar 2016 17:19:09 -0300
Message-ID: <8737rm2pc2.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

Tomi Ollila <tomi.ollila@iki.fi> writes:

> This is good opening for (eventually "fixing" e.g. library interface...);
> in its current state I can come up 2 (easily solvable) problems
>
> 1) the xapian database holding email indexes can grow to be quite large;
> user may have large space for emails (somewhere else than HOME) but small
> HOME. This can be "fixed" by keeping the database still in the same hierarchy
> as email files. Making user to point XDG_DATA_HOME elsewhere is (I) global
> and (II) fragile for an user to do.

Sure, once we find the database, the mail tree can be anywhere,
including the same place. The question is how do non-CLI clients find
the database. I agree that setting XDG_DATA_HOME just for notmuch sounds
ick. As you mention below we can fairly easily have our own environment
variable (NOTMUCH_DATABASE ?) that is checked in preference to XDG_DATA_HOME.

> 2) User may have multiple separate email configurations under one user
> account; This is easy to fix with environment variable; if exists,
> overrides XDG_DATA_HOME or $HOME/.local/share -- actually if this holds
> "only" configurations, the XDG_CONFIG_HOME is more appropriate
> (again, in simple case users should not be bothered to set any environment
> variables themselves, but should be able to survive with large databases).

For me, having an environment variable makes sense in terms of getting
various tools (scripts etc...) to cooperate. For multiple databases,
this seems less natural but of course the tools can still take some
parameter specifying a database. Also, I don't know how common it is for
people to have multiple databases.

d