nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] suppress Content-ID's with new mhbuild option? [really


From: Joel Reicher
Subject: Re: [Nmh-workers] suppress Content-ID's with new mhbuild option? [really more on design philosophy]
Date: Thu, 02 Feb 2006 17:18:41 +1100

> Joel wrote:
> > Perhaps you should create a new utility that writes build directives
> > and works both interactively and non-interactively, depending on the
> > command line options? If it is able to write both directives and
> > attachment headers, whatnow can use it for a *really* versatile way to
> > attach stuff, and it could also be used from many UNIX editors with
> > a shell.
> 
> Well, I have no need for such a utility which is why I haven't written
> one.  What I needed was a way to add attachments that could be used by
> non-geeks because I live with some.  The code that wrote for this
> several years ago accomplished this, and I have gotten good feedback
> from people who I don't know who have discovered and used this code.
> 
> This thread is the first that I've heard that people had other needs.
> Those needs are great, and feel free to contribute code that meets 'em.
> Write that utility.  Just do it in a way that doesn't break the existing
> stuff that is working for current users.
> 
> Not breaking existing stuff was one of the things that I thought a lot
> about when writing the attachment handling code.  That's why it's off
> by default, and the name of the attachment header field is specified by
> an option instead of being hard-wired to something that might conflict
> with one that somebody else might be using.
> 
> So again, feel free to contribute mime editors and builders and all of
> that sort of stuff.  If you need it, that's a good enough reason to do
> it; hopefully others will use it too.  Just don't break the existing
> stuff from the user perspective.  People are using it and are used to it.

Don't misunderstand me. While I don't need such stuff either, the purpose
of my suggestion was to keep the existing tools simple. I'm not a fan
of creeping features, and would like this stuff split off into a separate
tool past a certain point.

Cheers,

        - Joel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]