On January 28, 2010 at 19:15, markus schnalke wrote: > > Nmh should try to stay in-sync with Internet mail standards, > > This needs steady development of nmh in all involved fields (also > mail retrieval and transfer). By using external tools, only the core > job of nmh (= reading, organizing, and composing mail) needs to stay > in sync. Everything else will be in sync ``automatically''. (I know > ``automatically'' is an illusion.)
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. 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, 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. 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 (some software apps are setup to use an existing external component if available, and if not, use their version of the component). In sum, packaging and installation are important in a products usability and if users decide to use it. I've personally had to use this approach in several projects since reliance on external packages being installed (and installed correctly) created usability problems for users. > > not > > relying on external tools to support features MUAs are expected to > > support directly. > > ``are expected'' is the end in such discussions: Doesn't the world > expect MUAs to be monolithic? Doesn't the world expect web browsers > to be monolithic? (See uzbl.org) My statement is based upon a user's perspective. 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. A regular user should not have to know the difference. Usability matters. Maybe a question that needs answering is, "What type of user does nmh target?" Should an nmh user be a Unix weenie? Knowing the target user-base helps determine how nmh should be packaged and integrated with third-party components. IMO, basic user-perspective functions should be easy to do by the user. > 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 think mail retrieval and submission are core > > MUA functions, > > We are in total contrast in this point. They ARE essential from a user's perspective. I think it is a serious error to ignore the user's perspective. > It should support the standard mechanisms for its core tasks, yes. > But it should not include lots of stuff that is externally available. > You do use external libraries, why not use external programs? 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. 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. 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. For nmh, my biggest wish is TLS support. And from what I gather, there is NO solution that exists for this, either with the nmh core itself or via external programs. Neither ssmtp, msmtp, or nullmailer have interfaces that nmh expects (from what I gather from documentation). They function as drop-in replacements for sendmail and not as SMTP proxies. None support the -bs option, which nmh/MH use when in sendmail mode. If an external SMTP proxy solution is adopted, nmh can easily, behind the scenes, fork/exec an instance when the user selects 'send' or 'push', sends the SMTP commands to the instance for submission, and then terminate the instance once mail is submitted to the MTA (or instance self-terminates). This approach would eliminate the need for the user to explicitly configure another application, and any configuration settings needed can be part of the .mh_profile that nmh can grab and pass to the proxy instance. Just doing some seaching, I'm wondering if <http://www.delegate.org/delegate/> could be used. Looks like it may support being a basic SMTP proxy that can accept non-encrypted connections and rely to another host using TLS. --ewh _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers