22/41bc51afea263bd89a5550d9f86b187ced30f9

   1 Return-Path: <mh@glandium.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 A45C1431FBC\r
   6         for <notmuch@notmuchmail.org>; Fri,  8 Jan 2010 21:51:26 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id DbYt+p2Rk+Lz for <notmuch@notmuchmail.org>;\r
  11         Fri,  8 Jan 2010 21:51:26 -0800 (PST)\r
  12 Received: from vuizook.err.no (vuizook.err.no [85.19.221.46])\r
  13         by olra.theworths.org (Postfix) with ESMTP id A0F88431FAE\r
  14         for <notmuch@notmuchmail.org>; Fri,  8 Jan 2010 21:51:25 -0800 (PST)\r
  15 Received: from cha92-13-88-165-248-19.fbx.proxad.net ([88.165.248.19]\r
  16         helo=jigen)\r
  17         by vuizook.err.no with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)\r
  18         (Exim 4.69) (envelope-from <mh@glandium.org>) id 1NTUEL-0001y1-94\r
  19         for notmuch@notmuchmail.org; Sat, 09 Jan 2010 06:51:24 +0100\r
  20 Received: from mh by jigen with local (Exim 4.71) (envelope-from <mh@jigen>)\r
  21         id 1NTUEK-0000x0-7b\r
  22         for notmuch@notmuchmail.org; Sat, 09 Jan 2010 06:51:20 +0100\r
  23 Date: Sat, 9 Jan 2010 06:51:20 +0100\r
  24 From: Mike Hommey <mh+notmuch@glandium.org>\r
  25 To: notmuch@notmuchmail.org\r
  26 Message-ID: <20100109055120.GA3109@glandium.org>\r
  27 References: <874oo7hex2.fsf@yoom.home.cworth.org>\r
  28         <87y6lewqtw.fsf@convex-new.cs.unb.ca>\r
  29         <87638i75sz.fsf@home.veldthuis.com> <1260227209-sup-184@riseup.net>\r
  30         <874oo22blf.fsf@yoom.home.cworth.org>\r
  31         <20100108025620.GB28357@lapse.rw.madduck.net>\r
  32         <20100108080636.GA26839@glandium.org>\r
  33         <20100108090317.GB735@lapse.rw.madduck.net>\r
  34         <20100108092019.GA6671@glandium.org>\r
  35         <20100108102631.GB11257@lapse.rw.madduck.net>\r
  36 MIME-Version: 1.0\r
  37 Content-Type: text/plain; charset=us-ascii\r
  38 Content-Disposition: inline\r
  39 In-Reply-To: <20100108102631.GB11257@lapse.rw.madduck.net>\r
  40 X-GPG-Fingerprint: A479 A824 265C B2A5 FC54  8D1E DE4B DA2C 54FD 2A58\r
  41 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  42 Subject: Re: [notmuch] Quick thoughts on a notmuch daemon\r
  43 X-BeenThere: notmuch@notmuchmail.org\r
  44 X-Mailman-Version: 2.1.13\r
  45 Precedence: list\r
  46 List-Id: "Use and development of the notmuch mail system."\r
  47         <notmuch.notmuchmail.org>\r
  48 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  50 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  51 List-Post: <mailto:notmuch@notmuchmail.org>\r
  52 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  53 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  55 X-List-Received-Date: Sat, 09 Jan 2010 05:51:26 -0000\r
  56 \r
  57 On Fri, Jan 08, 2010 at 11:26:31PM +1300, martin f krafft wrote:\r
  58 > also sprach Mike Hommey <mh+notmuch@glandium.org> [2010.01.08.2220 +1300]:\r
  59 > > FYI, I have a good experience writing fuse filesystems, both with\r
  60 > > high-level and low-level APIs. I'd avise to use the low-level API,\r
  61 > > which allows for better performance.\r
  62 > \r
  63 > I don't have any experience with FUSE yet, but the examples in\r
  64 > /usr/share/doc/libfuse-dev/examples/ look trivial. This is where\r
  65 > I would start, one function at a time. If you have a better\r
  66 > suggestion, I'd love to hear it; or to clone your repo! ;)\r
  67 \r
  68 As I said above, there are 2 sets of APIs in FUSE.\r
  69 \r
  70 The high-level API sends the full path for the file being accessed for\r
  71 every system call. And except for specific cases such as read(), write()\r
  72 or readdir() you have nothing else to identify the file you are referring\r
  73 to, which means you have to parse the path, and find the proper file\r
  74 accordingly.\r
  75 In notmuch case, that would mean doing a search for most system calls.\r
  76 Try to imagine how many syscalls that are not read(), write() or\r
  77 readdir() mutt does when opening a Maildir.\r
  78 \r
  79 The low-level API, otoh, uses inode numbers extensively (again, except\r
  80 for read, write and readdir). The lookup call is responsible for resolving\r
  81 the paths, given an inode and a name. Its results are cached by the kernel.\r
  82 So, for example reading foo/bar from your fuse mount point will lookup\r
  83 foo in the inode 1 (FUSE_ROOT_ID) and then do another lookup for bar in\r
  84 the first result.\r
  85 One of the problems with this API is that the inode number type is\r
  86 unsigned long, which means you can't necessarily map real inode numbers,\r
  87 which can be 64 bits. And even if it could, afaik, there is no quick way\r
  88 to get a file from its inode, sadly.\r
  89 \r
  90 All in all, in the high-level API case, that means we would need lookups\r
  91 caching badly, and in the low-level API case, some fast way to map on\r
  92 one hand virtual directories with inodes numbers, and on the other hand,\r
  93 real files with inode numbers.\r
  94 \r
  95 Some quick thoughts, about the whole thing:\r
  96 - We will need to be careful about deduplication: if you copy a file\r
  97   from one directory to another, you don't want to have the copy in the\r
  98   underlying Maildir. But as you won't know until the file is totally\r
  99   written and closed...\r
 100 - We should probably allow extra files to be stored in the virtual\r
 101   Maildir (for example, courierimap stores stuff in a Maildir)\r
 102 - We may not need a client program at all, the "search directories"\r
 103   configuration could be handled via extended file attributes.\r
 104 \r
 105 I also had another not quite unrelated idea a while ago, that could have\r
 106 its value here: a generic data store, very much like the git object\r
 107 database (an idea would be to have the git object datastore be a special\r
 108 case of this generic data store, for possibly interesting compatibility),\r
 109 which would allow for better storage of the messages: if the maildir is\r
 110 exposed via fuse, why would you need a raw maildir for ? It would also\r
 111 allow easier deduplication of messages that are different but not quite:\r
 112 - Mailing list replies you get both directly and from the mailing\r
 113   list software, their headers have differences, but the files are mostly\r
 114   equivalent\r
 115 - Mail quotes are found in both the original message and its response.\r
 116 \r
 117 Mike\r