36/763e02363334a8c3e7e79ca322f0853fc9ac02

   1 Return-Path: <madduck@piper.oerlikon.madduck.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 DF8064196F2\r
   6         for <notmuch@notmuchmail.org>; Mon, 12 Apr 2010 05:39:03 -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=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 Ke2smViF2sLV for <notmuch@notmuchmail.org>;\r
  16         Mon, 12 Apr 2010 05:39:02 -0700 (PDT)\r
  17 Received: from clegg.madduck.net (clegg.madduck.net [193.242.105.96])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 47396431FC1\r
  19         for <notmuch@notmuchmail.org>; Mon, 12 Apr 2010 05:39:02 -0700 (PDT)\r
  20 Received: from piper.oerlikon.madduck.net (piper.oerlikon.madduck.net\r
  21         [IPv6:2a01:198:4e2:0:211:2fff:fe6b:c869])\r
  22         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  23         (Client CN "piper.oerlikon.madduck.net",\r
  24         Issuer "CAcert Class 3 Root" (verified OK))\r
  25         by clegg.madduck.net (postfix) with ESMTPS id 7C2A61D4099;\r
  26         Mon, 12 Apr 2010 14:38:54 +0200 (CEST)\r
  27 Received: by piper.oerlikon.madduck.net (Postfix, from userid 1000)\r
  28         id 48309CC; Mon, 12 Apr 2010 14:38:53 +0200 (CEST)\r
  29 Date: Mon, 12 Apr 2010 14:38:53 +0200\r
  30 From: martin f krafft <madduck@madduck.net>\r
  31 To: Michal Sojka <sojkam1@fel.cvut.cz>\r
  32 Subject: Re: [PATCH] Mailstore abstraction v4 - part 2 (maildir\r
  33         synchronization)\r
  34 Message-ID: <20100412123853.GA26402@piper.oerlikon.madduck.net>\r
  35 Mail-Followup-To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org\r
  36 References: <1270739592-30280-1-git-send-email-sojkam1@fel.cvut.cz>\r
  37         <20100412081805.GA25971@lapse.rw.madduck.net>\r
  38         <87hbngc2og.fsf@steelpick.2x.cz>\r
  39 MIME-Version: 1.0\r
  40 Content-Type: multipart/signed; micalg=pgp-ripemd160;\r
  41         protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS"\r
  42 Content-Disposition: inline\r
  43 In-Reply-To: <87hbngc2og.fsf@steelpick.2x.cz>\r
  44 X-Motto: Keep the good times rollin'\r
  45 X-OS: Debian GNU/Linux squeeze/sid kernel 2.6.33-2-amd64 x86_64\r
  46 X-Spamtrap: madduck.bogus@madduck.net\r
  47 X-Subliminal-Message: debian/rules!\r
  48 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  49 X-Virus-Scanned: clamav-milter 0.95.3 at clegg\r
  50 X-Virus-Status: Clean\r
  51 Cc: notmuch@notmuchmail.org\r
  52 X-BeenThere: notmuch@notmuchmail.org\r
  53 X-Mailman-Version: 2.1.13\r
  54 Precedence: list\r
  55 List-Id: "Use and development of the notmuch mail system."\r
  56         <notmuch.notmuchmail.org>\r
  57 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  59 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  60 List-Post: <mailto:notmuch@notmuchmail.org>\r
  61 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  62 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  63         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  64 X-List-Received-Date: Mon, 12 Apr 2010 12:39:04 -0000\r
  65 \r
  66 \r
  67 --qMm9M+Fa2AknHoGS\r
  68 Content-Type: text/plain; charset=iso-8859-1\r
  69 Content-Disposition: inline\r
  70 Content-Transfer-Encoding: quoted-printable\r
  71 \r
  72 also sprach Michal Sojka <sojkam1@fel.cvut.cz> [2010.04.12.1347 +0200]:\r
  73 > > Wouldn't it be better to postpone synchronisation of the tags\r
  74 > > until after emacs is done with the message?\r
  75 >=20\r
  76 > Theoretically, it would be possible, but if, for some reason, the\r
  77 > synchronization step would not happen, then the tags in the\r
  78 > database and in the mailstore will be inconsistent and next run of\r
  79 > notmuch new would reset the tags according to the state in\r
  80 > mailstore.\r
  81 \r
  82 Well, sure. But then again, notmuch (nor IMAP or Maildir) isn't\r
  83 transactional anyway. There are many other ways in which the\r
  84 database and store can get out of sync. And you are about to add\r
  85 another redundancy.\r
  86 \r
  87 > The current implementation takes tags in mailstore as\r
  88 > authoritative and ensures that tags in mailstore are always\r
  89 > updated before tags in the database.\r
  90 \r
  91 So why store them in the database at all?\r
  92 \r
  93 > > I understand this might be hard to make work with mailstore\r
  94 > > abstraction. Wouldn't it make more sense to have emacs call\r
  95 > > 'notmuch cat', which returns the entire message, removes the\r
  96 > > unread tag, changes the filename, and updates the database?\r
  97 >=20\r
  98 > I do not like the fact that cat would do two things - cat and tag.\r
  99 > And then, 'unread' tag is not the only one which can be changed.\r
 100 \r
 101 I wouldn't want an unread tag in the first place, especially not\r
 102 with Maildir semantics. In this case, what should really happen is:\r
 103 \r
 104   1. cat feeds a message to client\r
 105   2. client instructs notmuch to update tags\r
 106      - some tags require changes in the database\r
 107      - others require filename changes, which must be completed in\r
 108        unison with a database update so the new filename is stored.\r
 109   3. user asks to see attachment, which the client can fulfill using\r
 110      either a cached copy from (1.) in a tempfile, or by simply\r
 111      asking for the message again, via notmuch search.\r
 112 \r
 113 > > The message returned by cat would be stored in a temporary file\r
 114 > > for use by the client (emacs). And if the message was needed\r
 115 > > again, you could just search for it again.\r
 116 > >=20\r
 117 > > I dislike the idea of heuristically probing a Maildir for files.\r
 118 >=20\r
 119 > Well, I do not plan to use wired heuristics. At the end there will\r
 120 > be readdir() to traverse the cur/ directory to find the file with\r
 121 > the same part before flags. Since the S flag will probably be the\r
 122 > most frequent change, I may add one single test for added S flag\r
 123 > before trying more expensive readdir().\r
 124 \r
 125 What is the point of storing these tags in the Maildir anyway? If\r
 126 you want to make this information (e.g. new, seen, unread) available\r
 127 to MUAs accessing Maildir directly, keep in mind that the database\r
 128 and mailstore will very quickly grow inconsistent until the next\r
 129 notmuch-new run, e.g. as messages are moved, or flags ('F') are\r
 130 added in a way that the notmuch database is not updated.\r
 131 \r
 132 --=20\r
 133 martin | http://madduck.net/ | http://two.sentenc.es/\r
 134 =20\r
 135 "friendships last when each friend thinks he has\r
 136  a slight superiority over the other."\r
 137                                                    -- honor=E9 de balzac\r
 138 =20\r
 139 spamtraps: madduck.bogus@madduck.net\r
 140 \r
 141 --qMm9M+Fa2AknHoGS\r
 142 Content-Type: application/pgp-signature; name="digital_signature_gpg.asc"\r
 143 Content-Description: Digital signature (see http://martin-krafft.net/gpg/)\r
 144 Content-Disposition: inline\r
 145 \r
 146 -----BEGIN PGP SIGNATURE-----\r
 147 Version: GnuPG v1.4.10 (GNU/Linux)\r
 148 \r
 149 iEYEAREDAAYFAkvDFFwACgkQIgvIgzMMSnU7rQCgzTHgMBgdKX70W/TIFZ42WLU7\r
 150 3XoAnj88FKdu2GOy/pvWkjCFQlBsFoSr\r
 151 =JZUV\r
 152 -----END PGP SIGNATURE-----\r
 153 \r
 154 --qMm9M+Fa2AknHoGS--\r