On February 4, 2011, Ken Hornstein <kenh(_at_)pobox(_dot_)com> wrote:
Paul Vixie <vixie(_at_)isc(_dot_)org> 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/
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers