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

[markus schnalke]

[2010-01-28 14:07] Earl Hood <address@hidden>
> 
> 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