nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] indexing


From: Paul Vixie
Subject: Re: [Nmh-workers] indexing
Date: Sun, 06 Feb 2011 06:08:29 +0000

> Date: Sat, 05 Feb 2011 19:37:53 -0800
> From: Jon Steinhart <address@hidden>
> 
> I'm not an expert on IMAP.  I don't use it and know very little about it.

at this point i don't think anybody does, not even mrc -- it's gone organic.

> But not being completely afraid to make a fool out of myself I have
> two thoughts:
> 
>  1.  I added code to nmh years ago that calls external hook programs when
>      messages are inc'd, rmm'd, and refiled.  It does the right thing on
>      sortm too.  Probably not completely bug free but has worked fine with
>      an external program that I wrote that indexes mail and other stuff.
>      Can whatever is needed be accomplished by calling external programs
>      using this code?

yes!  i am using it.  i was *very* excited to find this when searching the
nmh sources.  i would have been excited to see grokmail, too, and i will be
when/if that gets finished.  but THANK YOU for putting in these hooks.  i
sent one patch to kenh concerning your work, because you failed to mention
*all* the places that your code does the RIGHT thing (+rcvstore and mhstore).

>  2.  Can IMAP unique IDs and such be stored as X-Header stuff?

that's how imap does this with other mail stores like ucbmail format.  but
in those formats the act of moving or copying a message between folders
necessarily involves copying the header, so giving it a new unique per-folder
UID is no problem.  if we had to rewrite a message every time we moved it,
it wouldn't feel much like MH any more.  and "refile -link" could not work.

more important is performance.  i'd like to be able to know thousands of UIDs
in a folder without opening thousands of files to get them.  and, basically,
i want MH itself to go faster, and an opportunistic index that made "scan"
run at wire speed and made "pick" hundreds of times faster (for header terms;
i'm not talking about full body indexing) makes it worthwhile to build the
scaffold for this.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]