[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
either.)
[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
http://harkless.org/dan/