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

[Ken Hornstein]

>This is flamebait, shame on you.

I disagree; I thought it was relatively straightforward, and not intended
as flamebait at all.

>> 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.

Um, no, I don't think that follows from my argument at all.  My argument
was, "Hey, I would find this feature useful, why should it not be added?"

>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?

It solves the problem of me wanting to access my IMAP mailbox via the
MH tools I'm used to.  I think that's a useful problem to solve; obviously
not everyone agrees.  This could enable things like exmh having IMAP
support (I admit, it would require some significant work to make this happen
from exmh's perspsective, but it would make it a lot easier).

>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.

Note that I have said several times; people interested in IMAP support
should just do it, rather than talk about it.  And while I share the concern
about nmh dying, I have a completely different perspective: I think new
features are the way to keep it alive!

--Ken