Re: [Nmh-workers] inc, slocal, procmail, ...

[Bill Wohler]

Ken Hornstein <address@hidden> writes:

>>> > 1) Local delivery from the MTA
>>> > 2) Fetch mail from the local maildrop
>>> > 3) Fetch mail from POP, IMAP and all the other methods supported by
>>> > fetchmail
>>> > 4) Accept mail from a third party program (i.e. be an mda for
>>> > fetchmail)
>>> 
>>> I think this is all great; we just need someone to write the code :-/
>>
>>At the other extreme, what's wrong with inc(1) handling nothing but 2
>>above?  The other things are others' problems that they can concentrate
>>on and do well.
>
> So I don't quite know where the line should be drawn.

One thing to keep in mind when thinking about that line is that inc is
typically synchronous, where our use of fetchmail/procmail (or whatever)
is asynchronous. By the time we step up to MH, everything is already in
a folder or in the local maildrop ready for +inbox (or already in
+inbox). I don't want to have to wait for inc to go to my remote server.

> But here's my
> feelings on the topic.
>
> - nmh should offer basic funtionality out of the box; adding other packages
>   can add functionality, but you should be able to do the basic job of sending
>   and receiving email without them.
>
> - The first two ways of receiving email are fast becoming extremely rare.
>
> - Saying, "Hey, we're an MUA that you should try out, except that we can't
>   actually RECEIVE email, you have to use this third-party program",
>   seems kinda wrong to me.
>
> - We don't have to do everything that fetchmail does; I'm happy with a
>   basic subset that most other MUAs support.
>
> Obviously this a issue on which reasonable people can disagree.
>
> --Ken
>
> _______________________________________________
> Nmh-workers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers
>

-- 
Bill Wohler <address@hidden> aka <address@hidden>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD