ad/aac34780c41323c5193173e880569f66b19521

   1 Return-Path: <dkg@fifthhorseman.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 156C26DE0243\r
   6  for <notmuch@notmuchmail.org>; Wed,  1 Jun 2016 07:14:10 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.018\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5\r
  12  tests=[AWL=-0.018] 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 Tj5EsRK_gCD4 for <notmuch@notmuchmail.org>;\r
  16  Wed,  1 Jun 2016 07:14:02 -0700 (PDT)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
  18  by arlo.cworth.org (Postfix) with ESMTP id 22DBA6DE01D0\r
  19  for <notmuch@notmuchmail.org>; Wed,  1 Jun 2016 07:14:02 -0700 (PDT)\r
  20 Received: from fifthhorseman.net (unknown [38.109.115.130])\r
  21  by che.mayfirst.org (Postfix) with ESMTPSA id 48C73F98B;\r
  22  Wed,  1 Jun 2016 10:13:57 -0400 (EDT)\r
  23 Received: by fifthhorseman.net (Postfix, from userid 1000)\r
  24  id 0808D2022D; Wed,  1 Jun 2016 10:13:57 -0400 (EDT)\r
  25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  26 To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
  27 Subject: Re: [RFC2 Patch 5/5] lib: iterator API for message properties\r
  28 In-Reply-To: <87pos1u14p.fsf@alice.fifthhorseman.net>\r
  29 References: <1463927339-5441-1-git-send-email-david@tethera.net>\r
  30  <1464608999-14774-1-git-send-email-david@tethera.net>\r
  31  <1464608999-14774-6-git-send-email-david@tethera.net>\r
  32  <8760tthfuy.fsf@zancas.localnet> <87pos1u14p.fsf@alice.fifthhorseman.net>\r
  33 User-Agent: Notmuch/0.22+16~g87b7bd4 (http://notmuchmail.org) Emacs/24.5.1\r
  34  (x86_64-pc-linux-gnu)\r
  35 Date: Wed, 01 Jun 2016 10:13:56 -0400\r
  36 Message-ID: <87eg8ht2sb.fsf@alice.fifthhorseman.net>\r
  37 MIME-Version: 1.0\r
  38 Content-Type: text/plain\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.20\r
  41 Precedence: list\r
  42 List-Id: "Use and development of the notmuch mail system."\r
  43  <notmuch.notmuchmail.org>\r
  44 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  45  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  46 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  47 List-Post: <mailto:notmuch@notmuchmail.org>\r
  48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  49 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  50  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  51 X-List-Received-Date: Wed, 01 Jun 2016 14:14:10 -0000\r
  52 \r
  53 On Tue 2016-05-31 21:52:06 -0400, Daniel Kahn Gillmor wrote:\r
  54 > Thanks for working on this, David!  I think this is going to be really\r
  55 > useful!\r
  56 \r
  57 just thinking about this series this morning in a bigger-picture way, i\r
  58 figure it's worth asking the hard questions now rather than later --\r
  59 maybe the answers are obvious, and we just need to write them down.\r
  60 Please accept these questions in the spirit of supportive inquiry :)\r
  61 Here goes:\r
  62 \r
  63 do we actually need this abstraction?  If we're aiming to build specific\r
  64 new features (the two i'm thinking of are cryptographic-session-keys and\r
  65 reference-adjustments), couldn't we implement those features explicitly\r
  66 in xapian with their own special prefix, rather than treating them as a\r
  67 generic "property"?  If we make a generic "property", that seems likely\r
  68 to be exposed to the user, who can then manipulate them directly\r
  69 externally from notmuch.\r
  70 \r
  71 We already have a bit of an uncomfortable fit with tags and special\r
  72 flags (encrypted, signed, attachment, etc), where some are expected to\r
  73 be set and cleared automagically and some are expected to be manipulated\r
  74 directly by the user.  Are we setting ourselves up for more of the same,\r
  75 or is there a principled way that a user can know which properties it's\r
  76 kosher for them to set and clear, and which ones they should leave\r
  77 alone?\r
  78 \r
  79 If we add new specific features, we could potentially augment the dump\r
  80 format explicitly for them, without having the property abstraction.  We\r
  81 already have some explicit features for each message (subject, from, to,\r
  82 attachment, mimetype, thread id, etc), and most of them are derived from\r
  83 the message itself, with the hope that it could be re-derived given just\r
  84 the message body.  Is there a distinction between properties that can be\r
  85 derived from the message body and properties that need to be\r
  86 additionally derived from some other data?\r
  87 \r
  88    --dkg\r