Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Ken Hornstein]

>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)
   chdir(maildir)
   folder_read(folder)
   m_convert(mp, msgnumbers)
   <iterate over selected messages in mp, by using m_name() on each one>
   seq_setunseen(mp)
   context_save()

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.

--Ken