d7/2e0ec39ecf782238ca3b74c7ed8347385e5134

   1 Return-Path: <jrollins@finestructure.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 olra.theworths.org (Postfix) with ESMTP id A31734196F0\r
   6         for <notmuch@notmuchmail.org>; Sat,  6 Nov 2010 13:12:39 -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.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-1.9, T_MIME_NO_TEXT=0.01] autolearn=ham\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 aV2PvNtRPruO for <notmuch@notmuchmail.org>;\r
  16         Sat,  6 Nov 2010 13:12:25 -0700 (PDT)\r
  17 Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 93AD340D14D\r
  19         for <notmuch@notmuchmail.org>; Sat,  6 Nov 2010 13:12:25 -0700 (PDT)\r
  20 Received: from servo.finestructure.net (cpe-74-66-82-137.nyc.res.rr.com\r
  21         [74.66.82.137])\r
  22         (user=jgr2110 author=jrollins@finestructure.net mech=PLAIN bits=0)\r
  23         by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id oA6KCNAj016264\r
  24         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT)\r
  25         for <notmuch@notmuchmail.org>; Sat, 6 Nov 2010 16:12:24 -0400 (EDT)\r
  26 Received: from jrollins by servo.finestructure.net with local (Exim 4.72)\r
  27         (envelope-from <jrollins@finestructure.net>) id 1PEp7e-0000GJ-DN\r
  28         for notmuch@notmuchmail.org; Sat, 06 Nov 2010 16:12:22 -0400\r
  29 From: Jameson Rollins <jrollins@finestructure.net>\r
  30 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  31 Subject: notmuch for documents\r
  32 User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1\r
  33         (i486-pc-linux-gnu)\r
  34 Date: Sat, 06 Nov 2010 16:12:17 -0400\r
  35 Message-ID: <87k4kqp5y6.fsf@servo.finestructure.net>\r
  36 MIME-Version: 1.0\r
  37 Content-Type: multipart/signed; boundary="=-=-=";\r
  38         micalg=pgp-sha256; protocol="application/pgp-signature"\r
  39 X-No-Spam-Score: Local\r
  40 X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7\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: Sat, 06 Nov 2010 20:12:39 -0000\r
  54 \r
  55 --=-=-=\r
  56 \r
  57 A little while ago on #notmuch, madduck and ojwb mentioned that they\r
  58 thought notmuch was overly focused on mail.  At the time I thought this\r
  59 was a silly criticism and defended notmuch as doing what it does\r
  60 *really* well and that we shouldn't expect notmuch to be all things to\r
  61 all people.\r
  62 \r
  63 Yesterday, however, I had the profound realization that madduck and ojwb\r
  64 are right.\r
  65 \r
  66 Notmuch stores database entries for email messages.  However, these\r
  67 messages are nothing more than simple rfc5322 [0] structured documents.\r
  68 They include nothing more than headers and a text body.\r
  69 \r
  70 Imagine now that I have a collection of ebooks, each stored in a single\r
  71 rfc5322-formatted text file:\r
  72 \r
  73 ------------------------------------------------------------\r
  74 From: Italo Calvino <italo@calvino.com>\r
  75 Subject: If on a winter's night a traveler\r
  76 Date: 1979\r
  77 \r
  78 You are about to begin reading Italo Calvino's new novel,\r
  79 ...\r
  80 ------------------------------------------------------------\r
  81 \r
  82 I store them all in a directory.  I now create a NOTMUCH_CONFIG with a\r
  83 database.path that points to that directory, and run notmuch.  Notmuch\r
  84 works *out of the box* (almost) perfectly to index my collection of\r
  85 ebooks.  All the notmuch commands work exactly as expected.  I can\r
  86 search through the bodies, search the titles, search for an author,\r
  87 search for a publication date, etc.  The emacs interface even works as\r
  88 expected.  Try it: it really works!  There are only a couple of very\r
  89 little things that are a little funky:\r
  90 \r
  91   * the "headers" in my ebooks aren't exactly intuitive ("From" instead\r
  92     of "Author", "Subject" instead of "Title", etc.) and there are some\r
  93     missing headers ("Publisher").  I also had to format some of them in\r
  94     a strange way (I had to add "<italo@calvino.com>" in the "From"\r
  95     field in order to get it to index properly for some reason).\r
  96 \r
  97   * The documentation keeps referring to "messages", even though my\r
  98     documents are books.  And there are some subcommands that don't seem\r
  99     to make sense ("reply" to a book?).\r
 100 \r
 101 But that's it!  Everything else works as a perfect ebook indexer.  I can\r
 102 of course even add tags to my books.  Beautiful.  It's really quite\r
 103 incredible how well it works for this out of the box.  The only other\r
 104 issue is that my ebooks don't come in rfc5322-formatted files.  I have\r
 105 to translate them for notmuch to work.\r
 106 \r
 107 So what would have to be tweaked in notmuch to make it work even better\r
 108 as an ebook indexer?\r
 109 \r
 110   * add some sort of translator to extract the "headers" and "body" from\r
 111     my non-rfc5322-formatted ebook files\r
 112 \r
 113   * allow me to specify which "headers" from my ebooks I want indexed\r
 114     ("Author", "Publisher", etc.)\r
 115 \r
 116   * tweak notmuch show to just open the ebook itself in an ebook reader\r
 117     instead of outputting it to stdout\r
 118 \r
 119   * tweak the documentation\r
 120 \r
 121 Those are not very big changes.  And yet, with these changes notmuch can\r
 122 now work for *many* other large classes of structured documents.\r
 123 \r
 124 Another real world example:\r
 125 \r
 126 I have hundreds of scientific journal articles on my computer.  They are\r
 127 all pdf files and each has a corresponding bibtex entry in a flat text\r
 128 file.  If notmuch could read the headers from the bibtex file and the\r
 129 body from the text in the pdf (ps2ascii), notmuch would work *perfectly*\r
 130 as an indexer for my scientific journal articles.\r
 131 \r
 132 So what do people think about this idea?  Does it make sense to look\r
 133 into extending notmuch to handle non-mail documents?  We definitely\r
 134 would *not* want to compromise notmuch as a mail indexer/reader.\r
 135 Notmuch is the best damn mail system there ever was and we wouldn't want\r
 136 to mess with that.  Does abstracting everything in notmuch from\r
 137 "messages" -> "documents" hurt it as a mail system?  What if just the\r
 138 back-end were abstracted, to allow for different front-ends for\r
 139 different classes of documents, i.e. "messages", "articles", "books",\r
 140 "rss feeds", etc.?  Are there any big problems with this proposal that\r
 141 I'm overlooking?\r
 142 \r
 143 I'm very interested to hear what others think about this idea.\r
 144 \r
 145 jamie.\r
 146 \r
 147 [0] http://tools.ietf.org/html/rfc5322\r
 148 \r
 149 --=-=-=\r
 150 Content-Type: application/pgp-signature\r
 151 \r
 152 -----BEGIN PGP SIGNATURE-----\r
 153 Version: GnuPG v1.4.10 (GNU/Linux)\r
 154 \r
 155 iQIcBAEBCAAGBQJM1bahAAoJEO00zqvie6q8dqAP/iWt3A64h397BZmg1jDmfLRq\r
 156 QmYG7uqKYOhVAzx5nwyUishOgf7dyJnD3FJv/KYc5WH5XvBGu6zIjoSoo708Qt0d\r
 157 JnG1upGysiarL+BDDii1N3EMicWuBBCFsIXW69opWlshQ7k7Jyk6fFmkBMNA4IS5\r
 158 jhFuzGFlA/28mePVkRusqVOd0yPeddWwKjaFJAr8OnKJvuuqPrw6PQPEs5u/DCfF\r
 159 Pp51z4gssYOukT/NoTH4oEHsiordZhlET7WAmGDoo9mj1MEI7VDPTTm4BMzBnVnf\r
 160 WbFBKdlR4KvAb566A+0c5RssNLkx6Vsc9NkQQL/MgbwoJHLlHQmPnuzh+qSgE9EJ\r
 161 nL1XWAejDL5dTtgt+L/qq4xHN1a5yUnWHpXkj7Msfz99gmQDnKzLypkCbA6wuK2g\r
 162 PJGQtntuhTRvhqvVHFbAy/vbN7CDVygzKTb7OzyhhWunV04Nsi4b7hvnjLJla+ZG\r
 163 bB3MtjQzvWRFym4/KyXURn0tEKWAEuMUksep0Nxul0goO6Ikbw9At3bdfixv2RxX\r
 164 Hm30REQAIIBEbDPJ54o1A1EKugLCrd/NZq/oWxOFWtAk3WvLVEnXfYUVuCEjNyOl\r
 165 8FyTVgP5f7ljz+6PVovhFJhlgb7L2a+32SCrBHr1Io59SsHYNs6A8lzg0FweObGp\r
 166 H04BMMxuYJ0BAVZiPXHs\r
 167 =vkhz\r
 168 -----END PGP SIGNATURE-----\r
 169 --=-=-=--\r