Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))

[Josh Bressers]

> >The suggestion to make an IMAP filesystem (as linux centric as the
> >original suggestion was) is clearly the direction that would allow
> >MH and IMAP to work together properly.   Embedding IMAP knowledge into
> >show, next, scan, pick, refile, ... just fails to meet almost any useful
> >objective.
> 
> With all due respect to kre, who has forgotten more about Unix than
> I will ever know ... I cannot disagree more.

This is flamebait, shame on you.

> 
> I have mail stored on an IMAP server.  I think it's perfectly
> reasonable that I should be able to do "scan +IMAP:inbox" (or however
> you want to indicate that a particular folder is on an IMAP server; I
> have no strong feelings on the matter), and I have yet to see anyone
> offer a reason why this is _not_ a "useful objective".  Yeah, an
> integrated MUA may do that better ... but I guess I don't see that as a
> reason to not add a feature to MH.  If we start using that as a metric
> for not adding features to MH, we might as well pack it up now and go
> home, because everyone is going to realize that most other MUAs do the
> things that they want better and nmh development will wither and die.
> Note that this has almost happened several times already.

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.

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?

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 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.
I see this discussion as wasted energy.  Who is going to add these
features, then who is going to maintain it?  Right now I don't think you
could add such a feature to nmh without causing its death.  The code is
already mostly unmaintainable, adding something this complex would make it
worse.

If someone has interest in actually doing this work, not just talking about
it, help me clean up the code.  There would be no reason nmh couldn't have
something like a folder plugin architecture, so those of you who want imap
support can have it, while people like me who have no need for it don't
have to worry about bugs in imap breaking anything else.

-- 
    JB