5d/213eb9eb8b29cd7a69c1874c93cb27d45cc477

   1 Return-Path: <dme@dme.org>\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 olra.theworths.org (Postfix) with ESMTP id 056A4431FC1\r
   6         for <notmuch@notmuchmail.org>; Fri,  2 Apr 2010 01:53:11 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.9\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-1.9] autolearn=unavailable\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id INQKLNfBcidq for <notmuch@notmuchmail.org>;\r
  16         Fri,  2 Apr 2010 01:53:10 -0700 (PDT)\r
  17 Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com\r
  18  [74.125.82.53])        by olra.theworths.org (Postfix) with ESMTP id 985734196F0       for\r
  19  <notmuch@notmuchmail.org>; Fri,  2 Apr 2010 01:53:10 -0700 (PDT)\r
  20 Received: by wwb22 with SMTP id 22so1273228wwb.26\r
  21         for <notmuch@notmuchmail.org>; Fri, 02 Apr 2010 01:53:09 -0700 (PDT)\r
  22 Received: by 10.216.170.147 with SMTP id p19mr542696wel.129.1270198388550;\r
  23         Fri, 02 Apr 2010 01:53:08 -0700 (PDT)\r
  24 Received: from ut.hh.sledj.net (host83-217-165-81.dsl.vispa.com\r
  25         [83.217.165.81])\r
  26         by mx.google.com with ESMTPS id g9sm19446874gvc.23.2010.04.02.01.53.05\r
  27         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  28         Fri, 02 Apr 2010 01:53:06 -0700 (PDT)\r
  29 Received: by ut.hh.sledj.net (Postfix, from userid 1000)\r
  30         id 36EBF5941EC; Fri,  2 Apr 2010 09:53:04 +0100 (BST)\r
  31 To: Carl Worth <cworth@cworth.org>, notmuch <notmuch@notmuchmail.org>\r
  32 In-Reply-To: <87bpe2j2vu.fsf@yoom.home.cworth.org>\r
  33 References: <87oci344n4.fsf@ut.hh.sledj.net>\r
  34         <87bpe2j2vu.fsf@yoom.home.cworth.org>\r
  35 From: David Edmondson <dme@dme.org>\r
  36 Date: Fri, 02 Apr 2010 09:53:04 +0100\r
  37 Message-ID: <87oci2xmkv.fsf@ut.hh.sledj.net>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: text/plain; charset=us-ascii\r
  40 Subject: Re: [notmuch] pull request\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Fri, 02 Apr 2010 08:53:11 -0000\r
  54 \r
  55 On Thu, 01 Apr 2010 14:09:57 -0700, Carl Worth <cworth@cworth.org> wrote:\r
  56 > On Thu, 01 Apr 2010 15:41:03 +0100, David Edmondson <dme@dme.org> wrote:\r
  57 > > Carl, a couple of patches that I'd like you to consider. They are the\r
  58 > > first two on the `dme' branch of git://github.com/dme/notmuch.git.\r
  59 \r
  60 The updated changes are on the 'dme-for-cworth' branch now.\r
  61 \r
  62 > > http://github.com/dme/notmuch/commit/f86254e4509ed02731aa3eaa8541df1f2d11e400\r
  63 > > > notmuch-show: Add unix and pretty dates to the JSON output\r
  64 > > > \r
  65 > > > Include a 'date_unix' and 'date_pretty' field in the JSON output for\r
  66 > > > each message. 'date_pretty' can be used by a UI implementation,\r
  67 > > > whereas 'date_unix' is useful when scripting.\r
  68 > \r
  69 > With "date_unix" it's easy enough to guess what the value is. But\r
  70 > "date_pretty" is much more ambiguous. I assumed that this would be an\r
  71 > RFC 822 date string, (but then found that it's the relative date that\r
  72 > "notmuch show" is using currently).\r
  73 > \r
  74 > I think I'd rather see that named "date_relative", (or dropped with the\r
  75 > expectation that callers can decide how to format dates on their own).\r
  76 \r
  77 I renamed it to 'date_relative'.\r
  78 \r
  79 Keeping the creation of the relative date strings in one place struck me\r
  80 as a good idea - there will consistency between the two places it is\r
  81 used (search mode and show mode) and if the `notmuch' command is\r
  82 localised the Emacs UI will immediately benefit.\r
  83 \r
  84 > > > The search terms should match only a single message\r
  85 > > > (e.g. id:foo@bar.com). The part number specified refers to the part\r
  86 > > > identifiers output by `notmuch show'. The content of the part is written\r
  87 > > > the stdout with no formatting or identification marks. It is not JSON\r
  88 > > > formatted.\r
  89 > \r
  90 > The above documentation isn't quite complete to me. Is MIME decoding\r
  91 > handled by this or not? Also, the documentation says the search terms\r
  92 > "should match" only one message, but what does the implementation do if\r
  93 > more than one message is matched? It would be good to document that as\r
  94 > well.\r
  95 > \r
  96 > More significantly, this level of documentation needs to be put into the\r
  97 > "notmuch help" output (instead of the placeholder that's there in the\r
  98 > current patch). It also needs to be added to the man page in\r
  99 > notmuch.1.\r
 100 \r
 101 The documentation is updated. Sorry for being lazy.\r
 102 \r
 103 > > The second of these (part) has been the topic of some\r
 104 > > discussion. There's a suggestion that a 'cat' subcommand or\r
 105 > > '--format=raw' option to the 'show' subcommand would be better. I'm not\r
 106 > > particular preference - I just wanted the functionality to use in the\r
 107 > > Emacs UI.\r
 108 > \r
 109 > One other approach that I imagined with the json output would be to\r
 110 > simply include all of the MIME parts of all messages directly in the\r
 111 > json-format output from "notmuch show". Does json have any particular\r
 112 > way of encodign a binary blob? If not, should we just have one single\r
 113 > encoding here? (Such as BASE64 within a json string?)\r
 114 \r
 115 I'm sure that JSON could express the blob. There were two reasons that I\r
 116 decided not to include the full message in the JSON output:\r
 117 \r
 118         - some of the parts can be very large, causing Emacs to spend\r
 119           considerably time loading the part (and consume a bunch of\r
 120           memory). This would be particularly noticeable in a thread\r
 121           where many of the messages include large parts - the UI will\r
 122           load all of the parts, even if you've already seen the\r
 123           message.\r
 124 \r
 125         - there are some parts that the UI will probably never display\r
 126           inline usefully (OpenOffice?). For those parts it's quite\r
 127           wasteful to have the UI pull them in.\r
 128 \r
 129 There's obviously a compromise to be had. If we agreed to include\r
 130 text/html parts in the JSON output it would make sense to me - maybe all\r
 131 text/* parts should be there. There are probably others that would be\r
 132 useful.\r
 133 \r
 134 The later 'display all parts' version of notmuch-show is able to use\r
 135 either inline or external content to display parts (it uses that\r
 136 included in the JSON output if present).\r
 137 \r
 138 dme.\r
 139 -- \r
 140 David Edmondson, http://dme.org\r