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