WIP: add metadata to dump output
authorDavid Bremner <david@tethera.net>
Sun, 10 Jan 2016 02:51:32 +0000 (22:51 +2000)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:20:49 +0000 (16:20 -0700)
69/78ffa140deb7aac427bb49c101a8bf7010800a [new file with mode: 0644]

diff --git a/69/78ffa140deb7aac427bb49c101a8bf7010800a b/69/78ffa140deb7aac427bb49c101a8bf7010800a
new file mode 100644 (file)
index 0000000..af5d0c1
--- /dev/null
@@ -0,0 +1,77 @@
+Return-Path: <bremner@tethera.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 3F2536DE02C9\r
+ for <notmuch@notmuchmail.org>; Sat,  9 Jan 2016 18:51:57 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.311\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=0.240,\r
+  RP_MATCHES_RCVD=-0.55, SPF_PASS=-0.001] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id lX7b7FVtuKJw for <notmuch@notmuchmail.org>;\r
+ Sat,  9 Jan 2016 18:51:55 -0800 (PST)\r
+Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197])\r
+ by arlo.cworth.org (Postfix) with ESMTPS id 791156DE01D3\r
+ for <notmuch@notmuchmail.org>; Sat,  9 Jan 2016 18:51:53 -0800 (PST)\r
+Received: from remotemail by fethera.tethera.net with local (Exim 4.84)\r
+ (envelope-from <bremner@tethera.net>) id 1aI66X-0007Cp-N3\r
+ for notmuch@notmuchmail.org; Sat, 09 Jan 2016 21:51:41 -0500\r
+Received: (nullmailer pid 29635 invoked by uid 1000);\r
+ Sun, 10 Jan 2016 02:51:47 -0000\r
+From: David Bremner <david@tethera.net>\r
+To: notmuch@notmuchmail.org\r
+Subject: WIP: add metadata to dump output\r
+Date: Sat,  9 Jan 2016 22:51:32 -0400\r
+Message-Id: <1452394301-29499-1-git-send-email-david@tethera.net>\r
+X-Mailer: git-send-email 2.6.4\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 10 Jan 2016 02:51:57 -0000\r
+\r
+It seems (at least to me) that xapian metadata is the right way store\r
+certain configuration data, including tag aliases [1] and perhaps some\r
+non-CLI specific configuration. On the other hand we don't want to\r
+have things lost if we dump and restore a database. Hence this series,\r
+which is a start at dumping and restore such config.\r
+\r
+The main idea here is that various classes of metadata can be defined\r
+by using prefixes, in exactly the same way as tags are defined for\r
+documents. This will hopefully help prevent e.g. config from stomping\r
+on tag aliases.\r
+\r
+The first 6 patches impliment iterators for simple "queries" on\r
+metadata. They are probably split a bit fine, but that's the way I\r
+developed them.\r
+\r
+The last 3 impliment the printing of metadata in dump output. In order\r
+to be upwardly compatible, it uses the old dodge of hiding things in\r
+comments. In fact the comment syntax (# in first column) was never\r
+well documented; this does mean that the notmuch dump output can be\r
+tested without breaking the current restore tests. I threw an @ in to\r
+help autodetection of formats; obviously this is not foolproof. On the\r
+other hand, I don't know how much people currently rely on comments in\r
+dump files, since notmuch doesn't generate them.\r
+\r
+There's lots of bikes to shed here. Probably the most important bits\r
+are the library API, the dump output format, and of course the ever\r
+tricky command line argument names.\r
+\r
+Getting the memory ownership semantics is tricky, especially with the\r
+mix of C++ objects and talloc. So I'd appreciate a critical eye on\r
+those bits of metadata.cc.\r
+\r
+[1]: id:1448504191-30974-1-git-send-email-igor.contato@gmail.com\r