From: Ethan Date: Sun, 1 Jul 2012 16:02:08 +0000 (+2000) Subject: Re: [RFC PATCH 00/14] modular mail stores based on URIs X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=93ea8f3261a143fda7aeef3190f1d76504e337b5;p=notmuch-archives.git Re: [RFC PATCH 00/14] modular mail stores based on URIs --- diff --git a/44/eeeeb104b373d62be3a90e88430dfe8d96606f b/44/eeeeb104b373d62be3a90e88430dfe8d96606f new file mode 100644 index 000000000..5ff3aa2c4 --- /dev/null +++ b/44/eeeeb104b373d62be3a90e88430dfe8d96606f @@ -0,0 +1,200 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 49766431FAF + for ; Sun, 1 Jul 2012 09:02:12 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.798 +X-Spam-Level: +X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 + tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, + FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id ppDft23gV5PP for ; + Sun, 1 Jul 2012 09:02:10 -0700 (PDT) +Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com + [209.85.220.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id EE8B7431FAE + for ; Sun, 1 Jul 2012 09:02:09 -0700 (PDT) +Received: by vcbf1 with SMTP id f1so3668325vcb.26 + for ; Sun, 01 Jul 2012 09:02:08 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=UeoCrT7iWqZ6Z/rdq9M9nP8td9UW6zCNti7yveOS2lo=; + b=TX0jkZbJQgm7exG1oTm8YIZj1IuG2umya2Rg8J0sAl36nFu6YpnI+yQl/TdOJK9+3R + Xz9uDmaB/QbggCiLiN+n2kd6OSvJ9c0mfoJL7YCHipW9T4mKuAWmcx3zg5MiB2fhaZfr + mbGMms5oVoY9+xDh8oWEdMD8VKApBBD7RmmghG3F4bVmLNnTVR/6uTfQXbdbYE4fjTRA + +E3BVE16aFo+AAfVlUBRg5rl9t6HQHb4xmCy9paxhMdHLwBuOtlNJVcD1M9jPREB4HPY + 5H84BlTUinzBGrETQ56Q8I10R+vmypPJYUvvYF9Qktrv8TjE18XE6aSpPSNAlssnnVze + 6Gcw== +MIME-Version: 1.0 +Received: by 10.52.17.207 with SMTP id q15mr3929265vdd.49.1341158528204; Sun, + 01 Jul 2012 09:02:08 -0700 (PDT) +Received: by 10.220.6.3 with HTTP; Sun, 1 Jul 2012 09:02:08 -0700 (PDT) +In-Reply-To: <87k3yrmahu.fsf@qmul.ac.uk> +References: <1340656899-5644-1-git-send-email-ethan@betacantrips.com> + <877gutnmf1.fsf@qmul.ac.uk> + + <87k3yrmahu.fsf@qmul.ac.uk> +Date: Sun, 1 Jul 2012 12:02:08 -0400 +Message-ID: + +Subject: Re: [RFC PATCH 00/14] modular mail stores based on URIs +From: Ethan +To: Mark Walters +Content-Type: multipart/alternative; boundary=bcaec5040a4ca93e8104c3c6cd04 +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sun, 01 Jul 2012 16:02:12 -0000 + +--bcaec5040a4ca93e8104c3c6cd04 +Content-Type: text/plain; charset=ISO-8859-1 + +Thanks for going through it, I know there's a lot to go through.. + +On Thu, Jun 28, 2012 at 4:45 PM, Mark Walters wrote: + +> I was thinking of just having one mail root and inside that there could +> be maildirs and mboxes. Everything would still be relative to the root. +> + +I'm hesitant to have directories that contain maildirs and mboxes. It +should be possible to unambiguously distinguish between a maildir file and +an mbox file (mboxes always start with "From ", no colon) but it sounds +kind of fragile. + +> 1. Are URIs the way to specify individual messages, despite bremner's +> > concerns about too much of the API being strings? Is adding another +> library +> > is the easiest way to parse URIs? +> +> In my opinion the nice thing about using strings is that it does not +> require +> any changes to the Xapian database to store them. I think using URIs may +> not be best though as they seem to be annoying to parse (as filenames +> can contain the same characters) and you seem to need to work around the +> parser in some cases. +> + +I think that's more the fault of the parser than of the URIs. If glib came +with a parser, that would be great. There aren't a lot of options for +pure-C URI parsing. Besides uriparser, there's also some code in the W3C +sample code library, but it looked like integrating it would be a pain so I +let it go. + +I wonder if the following would be practical: use // as the field +> separator: +> +> e.g. mbox://filename//start_of_message+length +> +> I think 2 consecutive slashes // is about the only thing we can assume +> is not in the path or filename. Since it is not in the filename I think +> parsing should be trivial (thus avoiding the extra library). +> + +Can you explain what you mean when you say that two consecutive slashes +can't appear in a URL? Ordinary filesystem paths can contain them, and so +can file: URLs. (I just looked up file:///home/ethan///////tmp and Firefox +handled that OK.) I've sometimes seen machine-generated filenames with +double slashes because that way you don't have to make sure the incoming +filename was correctly terminated before adding another level. + + +> Secondly, I would prefer to keep maildirs as just the bare file name: so +> the existence of // can be the signal that there is some other +> scheme. This is asymmetric, but is rather more backwardly compatible. +> + +Based on your and Jani's reasoning, I did this. Revised patch series +follows. + +Ethan + +--bcaec5040a4ca93e8104c3c6cd04 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +Thanks for going through it, I know there's a lot to go through..
On Thu, Jun 28, 2012 at 4:45 PM, Mark Walters = +<markwalters1009@gmail.com> wrote:
+ +
I was thinking of just having one mail root = +and inside that there could
+be maildirs and mboxes. Everything would still be relative to the root.
= +

I'm hesitant to have directories that contain mai= +ldirs and mboxes. It should be possible to unambiguously distinguish betwee= +n a maildir file and an mbox file (mboxes always start with "From &quo= +t;, no colon) but it sounds kind of fragile.
+ + +
+> =A01. Are URIs the way to specify individual messages, despite bremner= +'s
+> =A0concerns about too much of the API being strings? Is adding another= + library
+> =A0is the easiest way to parse URIs?
+ +

In my opinion =A0the nice thing about using strings is that it do= +es not require
+any changes to the Xapian database to store them. I think using URIs may +not be best though as they seem to be annoying to parse (as filenames
+can contain the same characters) and you seem to need to work around the +parser in some cases.

I think that's more the = +fault of the parser than of the URIs. If glib came with a parser, that woul= +d be great. There aren't a lot of options for pure-C URI parsing. Besid= +es uriparser, there's also some code in the W3C sample code library, bu= +t it looked like integrating it would be a pain so I let it go.
+ +
+ +I wonder if the following would be practical: use // as the field
+separator:
+
+e.g. mbox://filename//start_of_message+length
+
+I think 2 consecutive slashes // is about the only thing we can assume
+is not in the path or filename. Since it is not in the filename I think
+parsing should be trivial (thus avoiding the extra library).

Can you explain what you mean when you say that two consecutive = +slashes can't appear in a URL? Ordinary filesystem paths can contain th= +em, and so can file: URLs. (I just looked up file:///home/ethan///////tmp a= +nd Firefox handled that OK.) I've sometimes seen machine-generated fil= +enames with double slashes because that way you don't have to make sure= + the incoming filename was correctly terminated before adding another level= +.
+ +=A0
+ +Secondly, I would prefer to keep maildirs as just the bare file name: so +the existence of // can be the signal that there is some other
+scheme. This is asymmetric, but is rather more backwardly compatible.

Based on your and Jani's reasoning, I did this. Rev= +ised patch series follows.
+
Ethan

+ +--bcaec5040a4ca93e8104c3c6cd04--