bf/9f91a167cf65cdc478ec82e5c95331b84a2414

   1 Return-Path: <amdragon@mit.edu>\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 97ABD429E25\r
   6         for <notmuch@notmuchmail.org>; Sat, 10 Dec 2011 20:28:15 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 kDpdFWDdy4xj for <notmuch@notmuchmail.org>;\r
  16         Sat, 10 Dec 2011 20:28:15 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU\r
  18         [18.9.25.14])\r
  19         by olra.theworths.org (Postfix) with ESMTP id D0747431FB6\r
  20         for <notmuch@notmuchmail.org>; Sat, 10 Dec 2011 20:28:14 -0800 (PST)\r
  21 X-AuditID: 1209190e-b7f4a6d0000008e5-54-4ee4315db1cd\r
  22 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39])\r
  23         by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id F0.3F.02277.D5134EE4; Sat, 10 Dec 2011 23:28:13 -0500 (EST)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id pBB4SCSI016144; \r
  27         Sat, 10 Dec 2011 23:28:13 -0500\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pBB4SBh8023516\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Sat, 10 Dec 2011 23:28:11 -0500 (EST)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1RZb2s-0002i1-72; Sat, 10 Dec 2011 23:29:50 -0500\r
  37 Date: Sat, 10 Dec 2011 23:29:50 -0500\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Ciprian Dorin Craciun <ciprian.craciun@gmail.com>\r
  40 Subject: Re: Exporting a single email as JSON\r
  41 Message-ID: <20111211042950.GF2760@mit.edu>\r
  42 References:\r
  43  <CA+Tk8fycS4kmBRABRS4vFQLb3v0-ajcLZwPOwwEf98yvObgpwA@mail.gmail.com>\r
  44         <87zkf05gk4.fsf@servo.finestructure.net>\r
  45         <CA+Tk8fw+ky6hS0JGLQ4THOf+PSEZhSpfXRF=haayfAdF8HB6PQ@mail.gmail.com>\r
  46 MIME-Version: 1.0\r
  47 Content-Type: text/plain; charset=iso-8859-1\r
  48 Content-Disposition: inline\r
  49 Content-Transfer-Encoding: 8bit\r
  50 In-Reply-To:\r
  51  <CA+Tk8fw+ky6hS0JGLQ4THOf+PSEZhSpfXRF=haayfAdF8HB6PQ@mail.gmail.com>\r
  52 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  53 X-Brightmail-Tracker:\r
  54  H4sIAAAAAAAAA+NgFtrAKsWRmVeSWpSXmKPExsUixG6nrhtr+MTPYPVjJYuNE+6yWezZ52Vx\r
  55         /eZMZgdmj7unuTx2zrrL7vFs1S3mAOYoLpuU1JzMstQifbsEroxfzX9ZCqZIVPx91srawDhV\r
  56         uIuRk0NCwETi5usX7BC2mMSFe+vZuhi5OIQE9jFKfFu+lRHC2cAo0X5zF1TmJJPEka4DzBDO\r
  57         EkaJ2bubWUD6WQRUJT7+ngg2i01AQ2Lb/uWMILaIgKnEiwX/WEFsZoEIiSkzPjKB2MICuhKH\r
  58         /+8H6+UV0JaY+e0WE8TQQ4wSN+5sZYZICEqcnPmEBaJZR2Ln1jtAZ3AA2dISy/9xQITlJZq3\r
  59         zmYGCXMKBErM/ikPEhYVUJGYcnIb2wRG4VlIBs1CMmgWwqBZSAYtYGRZxSibklulm5uYmVOc\r
  60         mqxbnJyYl5dapGusl5tZopeaUrqJERQZnJJ8Oxi/HlQ6xCjAwajEw6vw8rGfEGtiWXFl7iFG\r
  61         SQ4mJVHecq0nfkJ8SfkplRmJxRnxRaU5qcVA73EwK4nwnu4EKudNSaysSi3Kh0lJc7AoifPW\r
  62         7nroJySQnliSmp2aWpBaBJOV4eBQkuCdZgA0VLAoNT21Ii0zpwQhzcTBCTKcB2j4JJAa3uKC\r
  63         xNzizHSI/ClGXY6dHQfOMAqx5OXnpUqJ8y4AKRIAKcoozYObA0torxjFgd4S5m0FqeIBJkO4\r
  64         Sa+AljABLfmS/QBkSUkiQkqqgdHjbrekl7V38l8u1U8vODnm9r29wFq36NpS+WkqBzmuzXHt\r
  65         tThe7bLRjeuVwMbXVec8V6nNCv106E7/KsVzh6fyPdJ4GrrjevSbDw0Ma/2lQ6exxe+4lHH8\r
  66         j7dMeM+MrpVrOzbwTiyqSvhSPXtL0YbLH4JlOQ443VCxOqOZUqR7LSZ6aRXLGxklluKMREMt\r
  67         5qLiRAAIEBWwQwMAAA==\r
  68 Cc: notmuch@notmuchmail.org\r
  69 X-BeenThere: notmuch@notmuchmail.org\r
  70 X-Mailman-Version: 2.1.13\r
  71 Precedence: list\r
  72 List-Id: "Use and development of the notmuch mail system."\r
  73         <notmuch.notmuchmail.org>\r
  74 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  75         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  76 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  77 List-Post: <mailto:notmuch@notmuchmail.org>\r
  78 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  79 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  80         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  81 X-List-Received-Date: Sun, 11 Dec 2011 04:28:15 -0000\r
  82 \r
  83 Just to add to Jameson's email...\r
  84 \r
  85 Quoth Ciprian Dorin Craciun on Dec 11 at 12:46 am:\r
  86 > On Sat, Dec 10, 2011 at 22:15, Jameson Graef Rollins\r
  87 > <jrollins@finestructure.net> wrote:\r
  88 > > On Sat, 10 Dec 2011 20:32:22 +0200, Ciprian Dorin Craciun <ciprian.craciun@gmail.com> wrote:\r
  89 > >>     Quick question: why isn't it reasonable to export a **single**\r
  90 > >> email in JSON format (by using the `show` sub-command)? (I mean I\r
  91 > >> understand that in order to be able to correctly parse the output we\r
  92 > >> need only one "object" (i.e. a list of threads, containing a list of\r
  93 > >> emails, etc.). But there might be use cases in which we need a\r
  94 > >> "twist".)\r
  95 > >\r
  96 > > Hi, Ciprian.  I agree that it would be nice too have the ability to\r
  97 > > output single messages without the rest of their thread.  I have on\r
  98 > > occasion wanted this functionality, but never enough to get around to\r
  99 > > implementing it.  It definitely wouldn't be that hard to implement,\r
 100 > > though.\r
 101 > >\r
 102 > > The notmuch show function is actually going through a pretty major\r
 103 > > overhaul at the moment.  I bet as soon as that's done we can get some\r
 104 > > sort of single-message output going.\r
 105 > >\r
 106 > > jamie.\r
 107 > \r
 108 > \r
 109 >     I've given a quick look into `notmuch-show.c` (commit from\r
 110 > December 4) and indeed it seems quite trivial to add new formats.\r
 111 \r
 112 I think it might make sense for formats to accept options that\r
 113 fine-tune their output in orthogonal ways, rather than guessing what\r
 114 consumers need.\r
 115 \r
 116 However, I don't think adding *new* formats is the way to go.  We need\r
 117 to be careful to limit the formats in order to prevent divergence.\r
 118 There's a lot of information notmuch show could include in its output\r
 119 and the few existing formats already include very different subsets of\r
 120 this information.  We don't want to get into a situation where, say,\r
 121 the array-JSON format evolves to includes one thing while the\r
 122 line-broken-JSON format evolves to includes another and consumers have\r
 123 to choose based on the information they need and not on what's easiest\r
 124 for them to consume.\r
 125 \r
 126 >     I think it's quite hard to get this feature "right". I.e. I can\r
 127 > see the following different -- but equally likely -- use-cases:\r
 128 >     * in my use-case I would need each line of the output to be a\r
 129 > standalone JSON object of an individual message; (thus I can script\r
 130 > with Bash `notmuch ... | while read message ; do ... ; done`;)\r
 131 \r
 132 As Jameson mentioned, similar things have been discussed in the\r
 133 context of notmuch search.  And the motivation there is related: we\r
 134 want it to be easy to consume one result at a time, which means it\r
 135 needs to be easy to know when the input is complete enough to pass to\r
 136 a JSON parser.  In the case of show, this doesn't have to be at odds\r
 137 with the existing format; we can leave the giant array for consumers\r
 138 that don't need the complexity of streaming, but ensure that newlines\r
 139 only appear between top-level array elements and nowhere else,\r
 140 providing an in-band framing for streaming consumers.  I'm not sure\r
 141 how you would do this with show, given its nested structure.\r