b5/57524721a05d73bd8a74c16cdff5dc7b6b86a6

   1 Return-Path:\r
   2  <return-v849zmfvbc8frapdqga98frzqi@temporary-address.scs.stanford.edu>\r
   3 X-Original-To: notmuch@notmuchmail.org\r
   4 Delivered-To: notmuch@notmuchmail.org\r
   5 Received: from localhost (localhost [127.0.0.1])\r
   6         by olra.theworths.org (Postfix) with ESMTP id 18FAA431FD0\r
   7         for <notmuch@notmuchmail.org>; Mon, 24 Jan 2011 11:10:19 -0800 (PST)\r
   8 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   9 X-Spam-Flag: NO\r
  10 X-Spam-Score: -2.3\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
  13         tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id RkKzrfEJkTm9 for <notmuch@notmuchmail.org>;\r
  17         Mon, 24 Jan 2011 11:10:18 -0800 (PST)\r
  18 Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 59601431FB6\r
  22         for <notmuch@notmuchmail.org>; Mon, 24 Jan 2011 11:10:18 -0800 (PST)\r
  23 Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
  24  [127.0.0.1])   by market.scs.stanford.edu (8.14.3/8.14.3) with ESMTP id\r
  25  p0OJAHZx020012 for <notmuch@notmuchmail.org>; Mon, 24 Jan 2011 11:10:17 -0800\r
  26  (PST)\r
  27 Received: from garage.uun.org.scs.stanford.edu (dm@localhost)\r
  28         by market.scs.stanford.edu (8.14.3/8.13.3/Submit) with ESMTP id\r
  29         p0OJAGHH007434\r
  30         for <notmuch@notmuchmail.org>; Mon, 24 Jan 2011 11:10:16 -0800 (PST)\r
  31 X-Authentication-Warning: market.scs.stanford.edu: dm owned process doing -bs\r
  32 Date: Mon, 24 Jan 2011 11:10:16 -0800\r
  33 Message-ID: <x78vyanmnb.wl@ta.scs.stanford.edu>\r
  34 From: dm-list-email-notmuch@scs.stanford.edu\r
  35 To: notmuch@notmuchmail.org\r
  36 Subject: Tag timestamps and synchronization\r
  37 User-Agent: SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=)\r
  38         APEL/10.8 Emacs/23.2 (x86_64-unknown-linux-gnu) MULE/6.0\r
  39         (HANACHIRUSATO)\r
  40 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")\r
  41 Content-Type: text/plain; charset=US-ASCII\r
  42 X-BeenThere: notmuch@notmuchmail.org\r
  43 X-Mailman-Version: 2.1.13\r
  44 Precedence: list\r
  45 Reply-To: David Mazieres expires 2011-02-24 PST\r
  46         <mazieres-468jumwyp2ei6jwxn8m5vrkyja@temporary-address.scs.stanford.edu>\r
  47 List-Id: "Use and development of the notmuch mail system."\r
  48         <notmuch.notmuchmail.org>\r
  49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  52 List-Post: <mailto:notmuch@notmuchmail.org>\r
  53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  55         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  56 X-List-Received-Date: Mon, 24 Jan 2011 19:10:19 -0000\r
  57 \r
  58 One of the features I would like to see from notmuch is an easier\r
  59 ability to synchronize tags across machines.  At the very least, I\r
  60 would need either incremental dump and restore, or some way to\r
  61 communicate arbitrary tags to a local imap server that shares\r
  62 notmuch's maildir (much as notmuch currently syncs the standard tags),\r
  63 so that I synchronize two maildirs with a tool like offlineimap.\r
  64 \r
  65 As Carl pointed out to me in private email, there has been some\r
  66 previous discussion in the following thread:\r
  67 \r
  68         notmuch show id:87hbfnmiux.fsf@yoom.home.cworth.org\r
  69 \r
  70 Based on that thread, there seems to be some desire for notmuch to\r
  71 keep track of a per-message timestamp when the flags were last\r
  72 updated.  This would allow much easier expiration for people who want\r
  73 the deleted tag.  It would also allow incremental dump and restore of\r
  74 tags, which is exactly what I need to sync tags across servers with\r
  75 reasonable amounts of bandwidth.\r
  76 \r
  77 Metadata timestamps are one of those things that probably have a lot\r
  78 of different applications, so since Carl is considering a new database\r
  79 format for the next release anyway, perhaps it also makes sense to add\r
  80 a metadata change time for each messages.\r
  81 \r
  82 The timestamp would be included in "dump" output, and you could\r
  83 request a dump of changes since a particular time.  On restore, you\r
  84 might have several options:\r
  85 \r
  86   - overwrite: always set the new tags and timestamp in the database\r
  87     to the value in the restore data.\r
  88 \r
  89   - update: always set the tags, but update the to the current time.\r
  90 \r
  91   - conditional T: update only if the message metadata has not been\r
  92     updated since time T.\r
  93 \r
  94 To sync flags, then you just need to keep track of the last time you\r
  95 synced with a particular server--call this time T.  Do a dump since\r
  96 time T, upload to server, do a conditional restore for time T on\r
  97 server.  Finally do a partial dump from time T on the server and an\r
  98 overwrite import on the client.  (This policy makes changes on the\r
  99 server always override conflicting ones on the client--perhaps people\r
 100 want other policies, like union of the tags, etc.)\r
 101 \r
 102 \r
 103 Second, there seems to be some desire in that thread to sync with IMAP\r
 104 flags.  This would be particularly great, but the easies way to do it\r
 105 is probably *not* to try to implement IMAP, but rather to use an\r
 106 existing IMAP server and just modify the maildir so that the IMAP\r
 107 server will pick up the flags.\r
 108 \r
 109 In the case of dovecot, the arbitrary tag format is very simple.  Each\r
 110 maildir has a file called dovecot-keywords mapping numbers 0, 1,\r
 111 ... to keywords.  Then mail file names contain lower-case letters for\r
 112 the flags they are marked with--0 => a, 1 => b, etc.--allowing up to\r
 113 26 arbitrary tags for each maildir.  One could probably sync to\r
 114 dovecot's maildir format relatively easily in a script given\r
 115 incremental dump and restore of tags.  Or possibly notmuch could\r
 116 natively support dovecot as one of multiple back-end tag storage\r
 117 schemes.\r
 118 \r
 119 Having a static tag mapping in the .notmuch-config file would be much\r
 120 better than hard-coding flag2tag.  However, I'm not sure it's\r
 121 sufficient.  The reason is that if you ever completely delete a tag\r
 122 (e.g., you have "todo", and "meeting" tags and periodically have no\r
 123 messages in either categories in a given mail folder), then an IMAP\r
 124 server like dovecot might end up re-allocating the letters\r
 125 corresponding to those tags in a different order.  Also, at least for\r
 126 dovecot, the flag mappings are per-folder, which you kind of want\r
 127 since you are limited to 26 non-standard tags, so global values might\r
 128 not work.\r
 129 \r
 130 I'm curious to hear people's thoughts/reactions?\r
 131 \r
 132 David\r