--- /dev/null
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 0D483431FBC\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 02:47:30 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+ autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id D7qub4AxKNYO for <notmuch@notmuchmail.org>;\r
+ Sat, 25 Jan 2014 02:47:21 -0800 (PST)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+ by olra.theworths.org (Postfix) with ESMTP id 8BF68431FB6\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 02:47:21 -0800 (PST)\r
+Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
+ by guru.guru-group.fi (Postfix) with ESMTP id 875031000B3;\r
+ Sat, 25 Jan 2014 12:47:13 +0200 (EET)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Jani Nikula <jani@nikula.org>, Austin Clements <aclements@csail.mit.edu>,\r
+ notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 0/5] lib: make folder: prefix literal\r
+In-Reply-To: <87r47wfltb.fsf@nikula.org>\r
+References: <cover.1389304779.git.jani@nikula.org>\r
+ <87y525m649.fsf@awakening.csail.mit.edu>\r
+ <87r47wfltb.fsf@nikula.org>\r
+User-Agent: Notmuch/0.17+41~g8e7fabf (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+ $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+ !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Sat, 25 Jan 2014 12:47:13 +0200\r
+Message-ID: <m2zjmks5hq.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 25 Jan 2014 10:47:30 -0000\r
+\r
+On Sat, Jan 25 2014, Jani Nikula <jani@nikula.org> wrote:\r
+\r
+> On Fri, 24 Jan 2014, Austin Clements <aclements@csail.mit.edu> wrote:\r
+>> On Thu, 09 Jan 2014, Jani Nikula <jani@nikula.org> wrote:\r
+>>> Hi all, this series makes the folder: search prefix literal, or switches\r
+>>> it from a probabilistic prefix to a boolean prefix. With this, you have\r
+>>> to give the path from the maildir root to the folder you want in full,\r
+>>> including the maildir cur/new component, if any. Examples:\r
+>>\r
+>> I strongly disagree with requiring the cur/new component. The cur/new\r
+>> directory is an internal implementation detail of Maildir (and a rather\r
+>> broken one at that) and no more a part of the "folder" of a piece of\r
+>> mail than its final file name component. It's also the less obvious\r
+>> user interface; if we require the cur/new component, we *will* get\r
+>> people asking why their folder searches aren't working, but if we strip\r
+>> the cur/new component, nobody will be surprised.\r
+>>\r
+>> I think the question is not whether we should strip cur/new, but when.\r
+>> We've already defined a "_filename_is_in_maildir" test in\r
+>> lib/message.cc, which we depend on for flag sync. It's simple, but I\r
+>> think this would be the right thing to use for consistency.\r
+>\r
+> I'd like to discuss some of the reasons I chose to include the cur/new\r
+> components. Admittedly, none of them are very strong on their own, but\r
+> all of them together tilted my opinion towards requiring them.\r
+>\r
+> The way I see it, notmuch supports maildir, but does not require it. In\r
+> many ways the messages are just files somewhere in the directory\r
+> hierarchy. There are only a few cases where it matters that there are\r
+> cur/new/tmp directories within a directory.\r
+>\r
+> If you strip cur and new, it becomes impossible to distinguish between\r
+> files in foo, foo/cur, and foo/new - and one of the reasons for changing\r
+> folder: in the first place is to be able to better distinguish between\r
+> folders.\r
+>\r
+> Apparently mutt presents the difference between messages in new and cur\r
+> to its users (so I've been told; I've never really used mutt), and our\r
+> integration with mutt lacks that distinction. We could fix that by\r
+> requiring the cur/new components in folder: searches.\r
+>\r
+> Speaking of consistency, compare _filename_is_in_maildir() with\r
+> _entries_resemble_maildir() in notmuch-new.c. What should the indexed\r
+> folder: prefix be if there is not all of cur, new, and tmp? We will\r
+> actually index files in tmp if cur or new is not present! What if the\r
+> missing sibling directories are added (or existing ones removed) later?\r
+> Where's the consistency compared to new.ignore config, which also\r
+> matches the cur/new components if so desired? Or consistency with\r
+> notmuch search --output=files?\r
+>\r
+> My conclusion was that requiring *all* filesystem folder components\r
+> as-is is consistent, most versatile, agnostic to Maildir or Maildir++\r
+> implementation details wrt directory naming or hierarchy, without\r
+> difficult corner cases, simplest to implement, and unsurprising (once\r
+> you understand the cur/new distinction).\r
+>\r
+> For *me* this is the more obvious user interface. And hey, I'm a user\r
+> too.\r
+>\r
+> Perhaps we need to have two prefixes, one of which is the literal\r
+> filesystem folder and another which hides the implementation details,\r
+> like I mentioned in my mail to Peter [1]. But consider this: my proposed\r
+> implementation does cover *all* use cases.\r
+\r
+I challenge that with my use case: my mails are arranged as follows: \r
+\r
+head of contents of notmuch archive prior to my involvement:\r
+\r
+$ find notmuch | head -5\r
+notmuch\r
+notmuch/6b\r
+notmuch/6b/de820df0697ab2d235fbc8e32510d7\r
+notmuch/6b/917afddb116a03c45371282be58388\r
+notmuch/6b/10eb0bc1406f6767161f5883f328f7\r
+\r
+head of contents of received mail\r
+\r
+$ find notmuch | head -5\r
+received\r
+received/rawmail2\r
+received/6b\r
+received/6b/86a8937aac57721ad87f0e0e5fe6c3\r
+received/6b/3278d6c4c1fe7604f1404bc09acff7\r
+\r
+Interestingly find started with subdirectory '6b' in both cases...\r
+-- anyway I have 0xff + 1 subdirectories in each mail directory and\r
+$ md5sum received/6b/86a8937aac57721ad87f0e0e5fe6c3 outputs\r
+6b86a8937aac57721ad87f0e0e5fe6c3 received/6b/86a8937aac57721ad87f0e0e5fe6c3\r
+\r
+For me the current folder: works as I don't have collisions.\r
+\r
+For me a folder: search which would just work as a prefix i.e. match\r
+anything under given directory hierarchy would work best.\r
+\r
+At the end it might be that I have to hack the search for my purposes;\r
+more important/interesting thing is whether I need to use incompatible\r
+database format :O\r
+\r
+\r
+Tomi\r
+\r
+\r
+>\r
+> BR,\r
+> Jani.\r
+>\r
+>\r
+> [1] id:8761ppurfz.fsf@nikula.org\r
projects / notmuch-archives.git / commitdiff