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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers