Return-Path: <BATV+6f12c9db5f767dfbbcf6+2608+infradead.org+hohndel@canuck.srs.infradead.org>
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 2FDD340D144
	for <notmuch@notmuchmail.org>; Wed, 13 Oct 2010 19:35:32 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
	tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 2rHg2LVPlpUa for <notmuch@notmuchmail.org>;
	Wed, 13 Oct 2010 19:35:21 -0700 (PDT)
Received: from canuck.infradead.org (canuck.infradead.org [134.117.69.58])
	by olra.theworths.org (Postfix) with ESMTP id 6912D40D142
	for <notmuch@notmuchmail.org>; Wed, 13 Oct 2010 19:35:21 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=x201s.gr8dns.org)
	by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux))
	id 1P6Df3-0006fl-Ms; Thu, 14 Oct 2010 02:35:18 +0000
Received: by x201s.gr8dns.org (Postfix, from userid 500)
	id 9FF4681BA5; Wed, 13 Oct 2010 19:26:49 -0700 (PDT)
From: Dirk Hohndel <hohndel@infradead.org>
To: Michal Sojka <sojkam1@fel.cvut.cz>,
	Servilio Afre Puentes <servilio@gmail.com>
Subject: Re: [PATCH 0/4] Maildir synchronization v2
In-Reply-To: <87r5ftomqt.fsf@steelpick.2x.cz>
References: <1286972038-21064-1-git-send-email-sojkam1@fel.cvut.cz>
	<AANLkTikurSji7OMGC192uTbpwvXN+htb1zw-YqBCc0bn@mail.gmail.com>
	<87r5ftomqt.fsf@steelpick.2x.cz>
User-Agent: Notmuch/0.3.1-105-g45d00c2 (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-redhat-linux-gnu)
Date: Wed, 13 Oct 2010 19:26:49 -0700
Message-ID: <m38w218q6u.fsf@x201s.gr8dns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SRS-Rewrite: SMTP reverse-path rewritten from <hohndel@infradead.org> by
	canuck.infradead.org See http://www.infradead.org/rpr.html
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."
	<notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 02:35:32 -0000

On Wed, 13 Oct 2010 22:34:34 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> On Wed, 13 Oct 2010, Servilio Afre Puentes wrote:
> > On 13 October 2010 08:13, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> > [...]
> > > THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
> > > unread messages doesn't work. The reason is that when you view the
> > > message its unread tag is removed which causes the file to be renamed,
> > > but Emacs still uses the original name to access the attachment. You can
> > > workaround this by closing the message and opening it again. This issue
> > > will be fixed after we (I) implement "notmuch cat" command. With this
> > > command, emacs would not access the messages by the file name, but by
> > > running notmuch cat id:<message-id> which will always give the correct
> > > content.
> > 
> > Wouldn't it be more efficient to query notmuch for the filename using
> > the message ID we store in the DB? When network usage is implemented,
> > tramp can give us transparent remote file access in emacs.
> 
> Tramp would not be available in non-emacs GUIs. Also, when notmuch cat
> is implemented, emacs gui will be usable remotely by simply defining
> notmuch-command variable to contain the name of the script containing:
> 
>      ssh user@host notmuch "$@"

That to me is certainly a very elegant solution... so what's stopping us
from implementing notmuch cat? No one taken the time to do it? Or is
there a design issue left to be resolved?

/D