From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 8E4356DE0032 for ; Sat, 19 Mar 2016 13:19:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-0.019, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMRZDSUT7t-n for ; Sat, 19 Mar 2016 13:19:14 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 7FB956DE0008 for ; Sat, 19 Mar 2016 13:19:14 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.84) (envelope-from ) id 1ahNLf-0006C5-M6; Sat, 19 Mar 2016 16:19:47 -0400 Received: (nullmailer pid 31598 invoked by uid 1000); Sat, 19 Mar 2016 20:19:09 -0000 From: David Bremner To: Tomi Ollila , notmuch@notmuchmail.org Subject: Re: [PATCH 6/6] WIP: support XDG database directory In-Reply-To: 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> 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 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2016 20:19:23 -0000 Tomi Ollila 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