Date: Wed, 3 Aug 2011 18:21:15 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Jameson Graef Rollins <jrollins@finestructure.net>
Subject: Re: [PROTO] possible solution for "Race condition for '*' command"
Message-ID: <20110803222115.GQ17291@mit.edu>
References: <20110703171743.GL15901@mit.edu>
	<1309762318-4530-1-git-send-email-pieter@praet.org>
	<e8c5fbf4-4dfa-461a-8f5c-6c696291a270@email.android.com>
	<87sjqldgr7.fsf@praet.org> <87iprg7dm0.fsf@praet.org>
	<20110705214234.GA15360@mit.edu>
	<CAH-f9WsPj=1Eu=g3sOePJgCTBFs6HrLdLq18xMEnJ8aZ00yCEg@mail.gmail.com>
	<87oc06i34f.fsf@servo.factory.finestructure.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87oc06i34f.fsf@servo.factory.finestructure.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Olly Betts <olly@survex.com>, Notmuch Mail <notmuch@notmuchmail.org>
Precedence: list

Quoth Jameson Graef Rollins on Aug 03 at  2:42 pm:
> On Wed, 3 Aug 2011 16:47:32 -0400, Austin Clements <amdragon@mit.edu> wrote:
> > The downside to using document ID's is that we need API's to expose
> > them.  My prototype exposes these as opaque "object ID"s, which acts a
> > lot like message IDs, but has no intrinsic meaning outside of the
> > library.  This needs two library functions: one to retrieve a
> > message's object ID and another to retrieve a message by object ID.
> 
> This sounds totally reasonable to me.  Maybe we could use something like
> "oid:" from the command line?

That would be difficult with Xapian's query parser (though, probably
fairly easy with the custom query parser).  This is one rough edge in
my prototype.  Currently, I have notmuch tag take an --objids flag
that makes it interpret the query as a whitespace-separated list of
object ID's instead of as a query string.  In a way, this makes sense,
but it would be annoying to do this to all of the commands.

We could special-case the query syntax and accept *either* a regular
query or an object ID query, but not a mixture of terms.  That would
be pleasantly forward-compatible and would address the special
handling in notmuch tag.  It would also give an easier path to fixing
the race condition, since we could fix it right away with message ID
queries and then move to object ID queries.  (Also, this could
eliminate the lookup-by-object-ID API function, though maybe we want
that anyway.)

> > 3x-4x isn't enough to make me jump on this added complexity, but it's
> > enough to make me consider it.  Carl, I'd love to hear your thoughts.
> 
> Imho 3x-4x is actually a pretty huge improvement.  Is it really that
> much of an added complexity to add those two functions?  That actually
> seems like a relatively simple patch to me.

The patch itself is only a few lines, but it adds a new concept.