[Nmh-workers] urls from mhpath, and message store abstraction layers.

[Lyndon Nerenberg]

On 2012-02-05, at 12:13 PM, Ken Hornstein wrote:

> % echo `mhpath 5 8 12`
> /tmp/.imapcache/88932 /tmp/.imapcache/92861 /tmp/.imapcache/1034785
> 
> Or whatever ... you get the idea.  mhpath would fetch the messages
> in question and put them somewhere local and return those pathnames.
> Sure, you could give a flag to mhpath to make it return IMAP URLs,
> but if we did that then I think we should return URLs for all
> messages.

In the IMAP case, you don't want to download the entire message just to satisfy 
an mhpath request. The value in IMAP is its ability to treat MIME sections as 
separate objects. By sucking down entire messages, all you've done is downgrade 
IMAP to POP.

MH could be a very good "disconnected mode" IMAP client, but getting this right 
involves a *lot* of subtleties.

But before chasing IMAP message stores (or any others), we have to address 
Paul's VFS-like abstraction layer for the message store interface. This has 
been done before (not in MH), and while it's conceptually straight-forward, 
there are a lot of fiddly things you must get right. I have designed and 
implemented a few of these message store virtual interfaces, including a very 
crude prototype in MH as part of a test to see how hard adding IMAP support 
would be. [Answer: hard ;-)  But not insurmountable.] Adding this to nmh is 
doable, but it's not something you can design by committee. If we're going to 
implement a VFS abstraction layer, a couple of people need to step up and 
volunteer to design and implement a prototype. This needs working code to shake 
out architecture bugs, and to provide scaffolding to work out the best way to 
expose this to the user commands.

--lyndon