[notmuch] wish: syncable/immutable threads

[Carl Worth]

On Tue, 15 Dec 2009 17:23:59 -0400, David Bremner <bremner at unb.ca> wrote:
> I then try to visit these threads on a different machine, but of course
> that thread id doesn't exist there, since the database was reindexed and
> tags reimported.

Ah, good point.

I've wanted reproducible thread IDs also for a similar reason. I
anticipate writing a tool to create HTML versions of the archives of
mailing lists. In this case I want to have thread IDs in URLs and I want
those URLs to be persistent even if I re-build the index from scratch.
(For this case, I'd also like to have small thread IDs, such as
consecutive integers.)

> I don't know if it is in any way practical, but it would be nice from my
> point of view if thread id's were a property of the mail collection, or
> at least it was possible to dump and restore them.

I think it's quite practical. The easiest answer is probably to simply
include the thread ID in each line of the dump output. And then we
should ensure that thread IDs as well as tags are accounted for in the
design of any synchronization mechanism to support multiple notmuch
databases. One thing to consider is whether we want to continue to have
any amount of compatibility with the sup dump format

> If this is too much of a corner case, then I suspect I can work around
> it in the emacs client by calling search twice, first with an id in the
> thread.

That's almost similar to what sup does, which is to use a message ID of
a the first message encoutered in a thread as the thread ID. Doing that
alone doesn't help with the case of rebuilding the index on separate
machines since it makes the thread ID dependent on the order in which
messages are processed.

But yes, if you can make your links depend only on message IDs then you
can get reliable results even before we start including thread IDs in
the dump output. The result of "notmuch show --entire-thread id:foo" is
quite similar to the result of "notmuch show thread:bar" (for the
corresponding thread ID of course). It differs only in the "match"
field, which is used to determine which messages to open by default.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091215/6098642b/attachment.pgp>