69/78ffa140deb7aac427bb49c101a8bf7010800a

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