> Using your argument, shouldn't the initial developers of mh just have used
> the commonly available mbox format then? There are certain things gained
> from the mh folder format, the people who cooked it up knew what they
> wanted.
That's an interesting idea, and it'd be nice to hear more. Feel free to
reply just to me if you think it'd just be noise on the list.
> I fail to understand what this discussion is all about. I agree that it
> would be nice if inc could suck mail from imap, but how is having the
> command line tools understand imap not outside of the scope of mh? This
> sounds like it could make a fine fork from the mh code, but I fail to see
> how such an addition can be classified as a part of mh. What is gained?
> Does this even solve a problem?
Surely all the arguments that apply to using IMAP in the first place
for any email at all also apply to MH+IMAP. I can use MH from a number
of different machines because my home directory is NFS mounted within
a small network, but NFS is not appropriate for all situations.
> Making this happen is going to require a lot of work. Making it work in a
> way that isn't just bolting a bag a manure onto the side of the current
> code will be a miracle.
I'll admit I haven't looked thoroughly at the IMAP spec, but from what I've
seen so far the mapping from MH commands to IMAP requests looks pretty good.
> I don't see nmh living for much longer unless things change. Most projects
> would be considered dead at this point, but somehow nmh is hanging on.
It's hanging on because there are still command-line users out there.
MH is the only command-line and shell oriented MUA that I know of.
Cheers,
- Joel
_______________________________________________
Nmh-workers mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/nmh-workers
