[Top][All Lists]

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

Re: [Nmh-workers] indexing [Paul Vixie's nmh + IMAP thread]

From: Dan Harkless
Subject: Re: [Nmh-workers] indexing [Paul Vixie's nmh + IMAP thread]
Date: Fri, 04 Feb 2011 19:53:49 -0800

On February 4, 2011, Ken Hornstein <address@hidden> wrote:
> Paul Vixie <address@hidden> wrote:
> >
> > hi all.  i havn't worked on mh in quite a while.  i sent kenh some patches
> > to use locking on the 'context' files back in 2003 and i see that those made
> > it in.  previously i guess it had been a REALLY long time since i hacked mh:
> Glad to see you're still using nmh, Paul!

Indeed!  This was enough to get me to de-lurk for the first time in quite
awhile.  (Well, having a *bit* more free time these days doesn't hurt

[Paul, I met you at a USENIX Security conference a couple of years ago, and
aside from picking your brain about DNSSEC, I was mainly thanking you for
all the software that you've written that I'm a happy user of, so it makes
me proud that you're also a user of software I've worked on.]

> >noting that slocal already links to either db, ndbm, or gdbm (according to
> >[...]

Although I was an slocal user for years, no doubt the vast majority of
people have moved to procmail, so whatever solution is picked shouldn't
depend on slocal to deliver (although I guess it'd be okay to require
procmail or other mail delivery agents to in turn call slocal or a new
helper program).

> So, when people talk about integrating nmh and IMAP, there are two distinct
> problems that people want to attack (AFAICT):
> 1) They want to have nmh and <insert your IMAP server here) read the same
>    message store, generally by having the IMAP server know about the nmh
>    folder format and pointing to to your home directory (which like
>    you said, some IMAP servers already sorta do, but there are
>    issues).
> 2) They want to use the nmh commands to access their IMAP folders.  So
>    "show" would talk to an IMAP server, scan would look through all of your
>    mailboxes on the IMAP server ... you get the idea.
> Long-time participants on this list already know all this; I'm just
> bringing everyone to the same page.
> As I understand it, what you want to solve is 1).  I personally
> wouldn't find that useful myself (because the IMAP server I would
> use wouldn't have access to my nmh mailboxes), but certainly plenty
> of people have asked about doing that, and I'm all for making nmh
> more useful to people.  Also, I don't think that doing 1) precludes
> doing 2).
> So, from what I understand this would require modifications to the IMAP
> server, right?  To know about these indexes?  As long as you've got the
> IMAP server vendors on board, then I guess I don't see any issues with
> that at all.  Sounds like a great idea to me, and it sounds like it's
> actually doable without a huge amount of work.
> What do others think?

Yep, I think most people would find #2 more useful and flexible, but any
work to get nmh and IMAP in the same room together would seem a big win for
nmh's future viability.

Recently I've been thinking that #2 would be easiest to achieve (and forgive
me since I'm probably rehashing past nmh-workers conversations that I
haven't had time to catch up on yet) by writing a new codebase mostly from
scratch (nnmh? ;^>) that had all the features that *most* nmh users use, but
left out the huge amount of legacy cruft and unused flexibility that makes
it a pain to work on the nmh codebase.

> (BTW, just as an aside ... when my wife asked me why I was up so late,
> I said I was replying to an email from Paul Vixie.  Her response:
> "Wait, _THE_ Paul Vixie?"  And no, she was NOT being sarcastic).

Good on ya for having a wife that recognizes the name.  ;^>

> > i can also imagine storing the full rfc822 header object in this index so
> > that "scan" and many forms of "pick" can operate at the speed of modern
> > hardware.  (stat()'ing ten thousand files in a directory has not gotten
> > faster over the years, whereas dbm_read()'ing 10000 elements has gotten
> > really quite fast compared to the vax 750 i first used MH on.)

Agreed -- this is my main pain point with nmh these days, taking over from
its poor MIME capabilities.  I have to admit, though, that rather than look
into how much work it'd be to incorporate a preindexing daemon into nmh, I
was thinking about just rebuilding my server to use an SSD drive for the
home directories as a workaround.

I know nothing about how IMAP servers deal with preindexing and field /
keyword searches initiated by the client (still on POP3 since nmh doesn't
talk IMAP in a meaningful way), but if they already handle that problem
well, then it'd sure be neat to magically gain fast search capability as a
side-effect of adding IMAP client support to nmh.

Dan Harkless

reply via email to

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