nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] Re: should nmh be an MTA or an MUA?

2010-01-29 04:40:25
[2010-01-28 14:07] Earl Hood <earl(_at_)earlhood(_dot_)com>

I think there is a mixing of user-based perspective vs design
perspective that should clarified.  From a user-based perspective,
things should just "work".  How that is achieved under the hood
is a design/implementation detail.

I mostly agree, but not in the word ``detail'', because I think this
is too important to be a detail.

What exactly do you mean with ``users''? If you mean people that are
no programmers, then I agree. If you mean us, then I don't.


As a user, I should not have to jump thru hoops to achieve basic
expected mail functionality, which includes the retrieval and
submission of mail.

I still think that the overhead is not so large. Usually, the
packaging system should cover this.


I, as a user, should not have to mess with downloading, installing,
configuring some external app to get basic TLS-based SMTP submission
of email.  I, thru nmh's configuration, should be able to do it easily
("Simple things should be simple to do.").  Now, if nmh relies on an
external package that is bundled with nmh to achieve the functionality,
so be it.

Now I see why we do not understand each other:
- For you, nmh is a system that provides everything for emailing.
- For me it is an MUA.

From your POV, nmh *should* include an MTA, a fetch program, and so
forth. From my POV, it should *not*.


You argue that package creaters should handle all the dependencies, but
that is not always an easy tasks with the myriad of *nix-based systems
out there, include linux ones that repackage things in varied ways.
I've seen numerous user complaints of something not working because OS
packagers decided to break up an OSS application into multiple RPMs,
where not all are installed by default.  Then a user complains to OSS
developers something is not working, when the the problem is because
a part of the app was not installed by the OS packaging system.

Sometimes it easier to just incorporate the external dependencies
into the nmh distribution itself to avoid OS package maintainers to
get things right

So you want to solve the symptomes, but the problem remains.

You are pragmatic. (I value this.)


Under-the-hood,
a particular component could be developed externally to the core
product, but it is bundled with the product.  It's just a matter of
packaging and how external components are integrated.

This matches our different views of what nmh is (mail system vs. MUA).

A regular user should not have to know the difference.

I agree.

Usability matters.  Maybe a question that needs answering is,
"What type of user does nmh target?"  Should an nmh user
be a Unix weenie?

I say: Write software for yourselfs, because otherwise you won't do
it well anyway.


Beware of the NIH syndrome. Unix is so good, because it *does* rely
on external software. That's what ``software leverage'' means.

I do not see anyone asking we implement our own TLS/SSL library
from scratch.

Even for IMAP, the discussion tends to lean towards leveraging
an existing IMAP implementation.

I want to motivate to forget the difference between library and
program.

Separate instead of integrate.


I think it is a serious
error to ignore the user's perspective.

I think it's bad to give the user's perspective a too high priority.
We're simply different in this point.


Real-world experience has taught me that reliance on external programs
can raise serious usability problems.  Therefore, packaging and
integration becomes critical when relying on external components,
either they being libraries or programs.

I know what you mean. I'm very idealistic is such points. I don't want
to go for (in my sense) ``wrong'' solutions.


The basic design philosophy of developing concise-well-defined
components that interact with each other is a good one and most
will agree with it.  I think where the real discussion is is on the
integration of those components.

Well said.

Is the burden more on the the
application developer-side or the end-user side?  I tend to lean
toward the developer-side to make end-user life easier.

Good point. Thus, I much favor good end-user howtos (this is different
to documentation). But I feel good design to be the higher goal.


meillo


_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>