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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers