[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] A useless but interesting exercise: Design MH from scr
Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context
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
maildir = m_maildir(folder)
<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.