[Top][All Lists]

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

Re: [Nmh-workers] A useless but interesting exercise: Design MH from scr

From: Ken Hornstein
Subject: Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
Date: Wed, 19 Feb 2014 20:59:26 -0500

>Though that could be replaced by a mhgrep that extracts
>messages from whatever form they're in and feeds them to
>grep (and caches due to likely locality of reference).

'pick' exists, although it doesn't support everything that grep does,
but it's pretty close.

>Analogous to what less(1) does with compressed files:  it just
>works.  With that, I could live with an IMAP, database,
>filesystem or other reasonable interface to whatever is used
>for actual storage.  It'd be nice if nmh supported any such
>interface if provided with a suitable adapter.
>Could we get there from here?  Probably but it would be
>painful, due to not being designed to support that kind of
>extension as well as having to support a storied legacy.
>I'd advocate starting over from scratch, which I think gets
>back to Norm's point.

You know, I've looked at the current API with an eye toward multiple
backends.  It's actually not terrible.  Here's a typical sequence of
things a program does (I'm using show(1) as an example) and omitting a
few steps)):

   maildir = m_maildir(folder)
   m_convert(mp, msgnumbers)
   <iterate over selected messages in mp, by using m_name() on each one>

The big things that stand out here are chdir() and directly opening each
message (you basically do an open() on the output of m_name()).  Other than
those two things, you have a reasonable start at an abstract API.  Define
a syntax where folder_read() (or a replacement) takes something that refers
to an IMAP mailbox, and you're most of the way there.  That's just the
user program API, of course ... the backends would require a lot of work.


reply via email to

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