From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id F370E431FB6 for ; Fri, 29 Jun 2012 00:44:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[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 aQU-12FpjKrZ for ; Fri, 29 Jun 2012 00:44:00 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 59062431FAF for ; Fri, 29 Jun 2012 00:44:00 -0700 (PDT) Received: by obbup19 with SMTP id up19so4689973obb.26 for ; Fri, 29 Jun 2012 00:43:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=wMpkD6oTjM/MDr/pnAtCuGwFmGyX4dKrdGalaa3GhOw=; b=dMb0FLX5U0STXouEeiD+eG2n6sf/B1wxs6U4YvrXxrLhphEkIm9ZJRomvAPLfrNAXZ EAlQnCb3y3vlpIJUzXE2JBhaImeo+mx7gr3urQMJpMYukr9dIiE4p12QDQCmmaeKaESq 9mGGzyYZ4aBedjYlMKorwFRcsLQ7d9WF0wIYYyLU3eVn1AcKApGEBQjyBUlJUhs/R2yg IitIMiT7+/iPZaGu0L51VxAI8WTmEqC4X9zIRvMkhK2gKTVpPA/XGiy1OM/mrJLBe63i 4m4YMOhUOlkbfSaZRIJTBAHyuuqlerKjpEEsf53uwajrC3IqhubbmoqCOvuAxm5AhBHk Gb+A== MIME-Version: 1.0 Received: by 10.182.139.2 with SMTP id qu2mr533447obb.34.1340955839690; Fri, 29 Jun 2012 00:43:59 -0700 (PDT) Received: by 10.76.10.102 with HTTP; Fri, 29 Jun 2012 00:43:59 -0700 (PDT) Received: by 10.76.10.102 with HTTP; Fri, 29 Jun 2012 00:43:59 -0700 (PDT) In-Reply-To: References: <1340656899-5644-1-git-send-email-ethan@betacantrips.com> <87bok3m70p.fsf@qmul.ac.uk> Date: Fri, 29 Jun 2012 10:43:59 +0300 Message-ID: Subject: Re: [RFC PATCH 00/14] modular mail stores based on URIs From: Jani Nikula To: Ethan Content-Type: multipart/alternative; boundary=e89a8f838db17bf7de04c3979c05 X-Gm-Message-State: ALoCoQkH91kNOFrxi2lIFl3aO3vycoBQ+CDyexImvXvD0FlM5KhrCFWMmG8ar3hOWEdzkHC7j+M2 Cc: Notmuch Mail 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: Fri, 29 Jun 2012 07:44:01 -0000 --e89a8f838db17bf7de04c3979c05 Content-Type: text/plain; charset=UTF-8 On Jun 29, 2012 9:43 AM, "Ethan" wrote: > > On Thu, Jun 28, 2012 at 6:00 PM, Mark Walters wrote: >> >> >> Just a quick question: does this update the database with >> maildir://files URIs instead of just filenames? In other words is it >> safe to try out on actual mailstores? > > > It doesn't change any of the existing filenames or do anything like a database "upgrade". If you run notmuch new, it should add a URI-based filename to each message, but I don't think it should remove old filenames, so I would expect it to be fine. But I didn't expect anyone to try it on their actual mail database. I don't have the time to look into the details, but I'd like to point out that one of the powerful features of notmuch is the cli and ability to pipe the commands. I'd hate to lose the ability to pipe 'notmuch search --output=files' to tools that don't understand uris. I suppose that means I'd like the most common case - files in maildir, the status quo - to use plain filenames. Either that, or notmuch search needs a new --output switch to output uris. A user that only has files in maildir should not experience any breakage because of this. BR, Jani. --e89a8f838db17bf7de04c3979c05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 29, 2012 9:43 AM, "Ethan" <ethan.glasser.camp@gmail.com> wrote:
>
> On Thu, Jun 28, 2012 at 6:00 PM, Mark Walters <markwalters1009@gmail.com> wrote:
>>
>>
>> Just a quick question: does this update the database with
>> maildir://files URIs instead of just filenames? In other words is = it
>> safe to try out on actual mailstores?
>
>
> It doesn't change any of the existing filenames or do anything lik= e a database "upgrade". If you run notmuch new, it should add a U= RI-based filename to each message, but I don't think it should remove o= ld filenames, so I would expect it to be fine. But I didn't expect anyo= ne to try it on their actual mail database.

I don't have the time to look into the details, but I'd like to = point out that one of the powerful features of notmuch is the cli and abili= ty to pipe the commands. I'd hate to lose the ability to pipe 'notm= uch search --output=3Dfiles' to tools that don't understand uris. I= suppose that means I'd like the most common case - files in maildir, t= he status quo - to use plain filenames. Either that, or notmuch search need= s a new --output switch to output uris. A user that only has files in maild= ir should not experience any breakage because of this.

BR,
Jani.

--e89a8f838db17bf7de04c3979c05--