--- /dev/null
+Return-Path: <ciprian.craciun@gmail.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 3E88E431FC2\r
+ for <notmuch@notmuchmail.org>; Tue, 14 Aug 2012 10:05:13 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.799\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
+ tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+ FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id uhSEJWkQGR-0 for <notmuch@notmuchmail.org>;\r
+ Tue, 14 Aug 2012 10:05:12 -0700 (PDT)\r
+Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com\r
+ [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 6B921431FAE\r
+ for <notmuch@notmuchmail.org>; Tue, 14 Aug 2012 10:05:12 -0700 (PDT)\r
+Received: by wibhm6 with SMTP id hm6so3900887wib.2\r
+ for <notmuch@notmuchmail.org>; Tue, 14 Aug 2012 10:05:11 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
+ h=mime-version:in-reply-to:references:date:message-id:subject:from:to\r
+ :content-type; bh=mD/ocqYSMyihREvcSf2OeRlzDTXe6KGu6E71JFKcjOU=;\r
+ b=bEHA28V/kNaVHIEBjP5F7AZRnTpzOnOdYcRkvpXsylOOpVznfBlc2wGFfMACFX7wD5\r
+ zp95auKVotrL6rcm1+D7LBk7mh2FrJwLYb9DK4P4Rw4aULP8vgS8fZAbyg8DZ16UKl5G\r
+ U7b7PvruXWSUf4vHXCx4bMZXaYRMezNEqFQxY9P2rIBlGkPMteVnT55etnBI3UsWyi5s\r
+ Fy31ZoEWAclADghSwS00xyzBZCD2twwRe0rtzDLQi96aQ2PINKhZkGOqCxWY/qIB1g4e\r
+ 3dg66huhl8V5xeR8c83sjW+T5FzxA532a0RdfZYc05Df8uzjf6h9MYgX07pu/yH74JQL\r
+ eAjg==\r
+MIME-Version: 1.0\r
+Received: by 10.180.74.33 with SMTP id q1mr29483925wiv.4.1344963911172; Tue,\r
+ 14 Aug 2012 10:05:11 -0700 (PDT)\r
+Received: by 10.180.104.196 with HTTP; Tue, 14 Aug 2012 10:05:11 -0700 (PDT)\r
+In-Reply-To: <20120814165044.GP28321@pub.cz.oracle.com>\r
+References:\r
+ <CA+Tk8fwq2thNeKHgfG-EX0hgR7uyqrSce0ZMOhEJBsz1RVtRqg@mail.gmail.com>\r
+ <20120811094635.GY28321@pub.cz.oracle.com> <874no613ms.fsf@flamingspork.com>\r
+ <20120814160442.GO28321@pub.cz.oracle.com>\r
+ <CA+Tk8fwVwWewTS-AVaaapQpLNU6a698acp-_ZmnktJ5ynRrx1A@mail.gmail.com>\r
+ <20120814165044.GP28321@pub.cz.oracle.com>\r
+Date: Tue, 14 Aug 2012 20:05:11 +0300\r
+Message-ID:\r
+ <CA+Tk8fwT4Hb3upMoucWUBeP8RMo6hTMi5zkH1HcPC6dhkS60wg@mail.gmail.com>\r
+Subject: Re: Alternative (raw) message store (i.e. instead of maildir)\r
+From: Ciprian Dorin Craciun <ciprian.craciun@gmail.com>\r
+To: Vladimir.Marek@oracle.com, Stewart Smith <stewart@flamingspork.com>, \r
+ notmuch@notmuchmail.org\r
+Content-Type: text/plain; charset=UTF-8\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 14 Aug 2012 17:05:13 -0000\r
+\r
+On Tue, Aug 14, 2012 at 7:50 PM, Vladimir Marek\r
+<Vladimir.Marek@oracle.com> wrote:\r
+>> On the other hand I strongly sustain having a more optimized\r
+>> backend for emails, especially for such cases. For example a\r
+>> BerkeleyDB would perfectly fit such a use case, especially if we store\r
+>> the body and the headers in separate databases.\r
+>>\r
+>> Just a small experiment, below are the R `summary(emails)` of the\r
+>> sizes of my 700k emails:\r
+>> ~~~~\r
+>> Min. 1st Qu. Median Mean 3rd Qu. Max.\r
+>> 8 4364 5374 11510 7042 31090000\r
+>> ~~~~\r
+>>\r
+>> As seen 75% of the emails are below 7k, and this without any compression...\r
+>>\r
+>> Moreover we could organize the keys so that in a B-Tree structure\r
+>> the emails in the same thread are closer together...\r
+>\r
+> Now I'm not sure if you talk about some berkeley-db fuse filesystem or\r
+> direct support in notmuch.\r
+\r
+ No tricks. :)\r
+\r
+ I proposed -- better said queried if possible or at least wanted\r
+-- to have an internal interface (SPI) that any mail store would have\r
+to implement in order to be indexed and used by notmuch. I guess the\r
+interface would be quite lightweight, and would need just the\r
+following:\r
+ * open store;\r
+ * create a cursor iterating through all the emails, yielding only the keys;\r
+ * read the envelope (as a byte blob) of a particular key; (used\r
+only for displaying thread lists, etc.;)\r
+ * read the body (as a byte blob) of a particular key;\r
+ * maybe create a cursor iterating over all those emails that have\r
+changed since a particular timestamp;\r
+\r
+\r
+> I don't have enough cycles to modify notmuch,\r
+> so I started to look at simpler (codewise) solution ...\r
+>\r
+> To summarize, what I personally want from the mail storage\r
+\r
+ We need to make a distinction between current storage (like\r
+maildir) and archival storage (like the Zip or my proposal).\r
+\r
+\r
+> - ability to read and write mails\r
+\r
+ It could be done through a small CLI over the proposed API.\r
+\r
+> - should work with mutt (or mutt-kz)\r
+\r
+ This would eliminate any proposal not involving a FUSE wrapper...\r
+\r
+> - simple backup to windows drive (files can't contain double colon ':')\r
+\r
+ This could be done via a dump like facility. (BerkeleyDB supports\r
+this natively through a tool.)\r
projects / notmuch-archives.git / commitdiff