Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Ken Hornstein]

>Sure, but reading this list for several years I have the impression,
>that more effort goes into finding consensus than on writing code.

I guess that's a fair criticism, but I think that's unavoidable with
a software project in this situation.

Remember that the ORIGINAL MH was developed in 1979.  So we've got a
software package that's over 30 years old; that's ... what, 3 lifetimes
in terms of Internet time? :-)  The original people aren't involved
anymore.  Well, okay, John Romine is still around (nice to hear from you!),
and we've seen messages from Norman Shapiro not too long ago.  Jerry
Peek is a lurker who pops up now and then.  Richard Coleman, the guy who
forked nmh, isn't doing that anymore.  So, the question THEN becomes ...
who's in charge of nmh?

Is it me?  Is it Jon Steinhart?  Is it Peter Maydell?  We're all listed
as nmh admins on the savannah web pages, but are we "in charge"?  I
think if one of us wanted to be in charge, the others wouldn't fight it
too much.  I think (but I don't want to speak for the others) that our
personalities don't work that way; each of us wants nmh to succeed, but
nmh isn't quite important enough to us to devote the time/energy to be
the guy who is willing to adhere to a vision and occasionally run
roughshod over the objections of others (because, in my mind, that
really is what being in charge means: occasionally you're going to have
to be the asshole).

So, we're in a situation where nmh works in a certain way; we want to
change it, but we don't know how that change will affect others.  So we
solicit feedback and try to build a consensus for a change.  Because in
my mind, nmh really belongs to everyone; while I may (occasionally)
shepherd it in a particular direction, I want it to succeed so that others
find it useful, and to do that I need to make sure that other people find
it useful as well.

Also, given the fact that (n)mh is 30+ years old, people have strong
opinions about the way it should work; I do try to be sensitive to
that, and I think others feel the same way as well.  So it's a
balancing act between the way MH currently works versus the way it should
work, and of course not everyone agrees on the way it SHOULD work.  Add
to that the fact that most of us have lives not in front of a computer,
and we're working on nmh in our free time, and people tend to be
focused on what is important to them personally rather than the long-term
vision.

>All I wanted to say is: This situation encourages people to think of
>work arounds instead of reporting bugs. So the fact that no bugs were
>reported is very weak evidence that everybody agrees on the current
>behaviour.

I for one understand that.  I don't necessarily think that people are
happy with the way nmh works, but that's why we're having these
conversations - to figure out nmh SHOULD work.  I think that's an
inefficiency we have to live with, unless someone wants to step up
and be the occasional asshole.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [really non-ASCII message bodies ]

[Oliver Kiddle]

Peter Maydell wrote:
> Has there been much of interest gone in since 1.3 to merit a 1.4?

If not, we could still release a 1.3.1. I'm a fan of the release early,
release often principle.

> I did the 'turn handle, release nmh' work last time round but I'm
> currently horribly busy so am unlikely to be able to do that before
> next year. If somebody else is willing to do it I don't object.

I'm happy to volunteer to turn the handle this time if you're currently
busy but a release now is deemed to be a useful thing to do.

So, is there anything half finished currently in git?

Oliver

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [really non-ASCII message bodies ]

[Peter Maydell]

Ken Hornstein wrote:
>>That's what (as I understand it) Jon's patch handles (I still use the
>>latest released version of nmh, which predates all this stuff ... there
>>hasn't been a new release (since 1.3) for a long time now...) and makes a
>>standards conforming message.
>
>You know, this has been bugging me.  Should we cut a new release?  I kinda
>think it's long-overdue.
>
>I'm thinking that what we have now (modulo any autoconf cleanup, which
>I've been itching to work on) should be 1.4, and whatever comes out of
>this MIME discussion should be post-1.4.  Or do people want to include
>this new MIME work?

Has there been much of interest gone in since 1.3 to merit a 1.4?

I certainly agree that this MIME rework should be either all in the
next release or not in it at all -- we don't want to accidentally
release half-a-change.

I did the 'turn handle, release nmh' work last time round but I'm
currently horribly busy so am unlikely to be able to do that before
next year. If somebody else is willing to do it I don't object.

-- PMM

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Harald Geyer]

> >Well, I always considered the current behaviour a bug, but I didn't say
> >anything, because the nmh-way of software development seemed pretty 
> >inefficient and I didn't want to look at the code myself either.
> 
> We have a "way" of software development?  When did that happen? :-)
> 
> In all seriousness ... what, exactly, do you mean?  I guess our current
> way is, "Anyone who's interested, please contribute!".  I don't see how
> that's really much different than other open-source packages.

Sure, but reading this list for several years I have the impression,
that more effort goes into finding consensus than on writing code.

Don't get me wrong: So far I wrote one patch for nmh which eventually
got accepted (some much edited version anyway). I learned a lot from
this about programming in C and I really appreciate all the
constructive feedback.

All I wanted to say is: This situation encourages people to think of
work arounds instead of reporting bugs. So the fact that no bugs were
reported is very weak evidence that everybody agrees on the current
behaviour.

Harald

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [really non-ASCII message bodies ]

[Jon Steinhart]

> Even for attachments, as I understand it, that's keyed off a pseudo-header
> added to the components file (and so appears in the draft), right?   Do we
> really need a switch to enable that.   I'm (again) all for backwards
> compatability, but is there any serious believe that people are really
> adding "Attachment:" (whatever it is, "MH-Attach:" might be better) headers
> to their messages and expecting that to be delivered?And yes, I know
> non-standard headers are OK, but we have non-switch-enabled locally invented
> headers used for this kind of purpose already (like fcc) - another,
> expecially if given a MH specific name, should be harmless.  It would be
> simpler to just do the processing and not require a switch (switches that
> we more or less tell people that "everyone should have this in their profile"
> are just dumb...)

Let me explain how the code works here.  There needed to be some way track
attachments for a draft between programs because of the modular nature of
nmh.  I suppose that I could have used a shadow file, but instead I used a
legal "X" header.  However, there is no way that I could 100% guarantee that
any X header wouldn't collide with something that some user was doing since
that namespace is uncontrolled.  That's why the name of the header that
tracks attachments is settable.

All attachment headers are stripped off by send before the message is sent.
Send examines the headers and changes the draft into a MIME message that
includes the attachments specified by those headers.

I can see where one could claim that this approach was overkill and could have
just been hardwired.  This was my first contribution to nmh and it was a rather
large change in functionality.  It was clear from reading the mailing list that
breaking things was bad, so I went about this in a safe way.

Had I received this input a decade ago I might have done things differently.
But, I didn't.  I am aware of users with custom environments who build drafts
with these attachment headers.  I don't see anything so compelling in changing
the name of the header field name that it's worth breaking things for these
users.

It's done.  Hindsight is wonderful but at some point you gotta let go.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ reallynon-ASCII message bodies ]

[David Levine]

Oliver wrote:

> > > These are definitely just wrong -- we shouldn't be specifying
> > > name and x-unix-mode for the body text
> 
> Yes, that's badly wrong. I've never used -attach, one of the reasons being
> that I didn't like it including x-unix-mode. Another thing that bothered
> me was that I couldn't get it to apply the attachments but defer sending
> so that I could run list to see the results.

I quickly got used to that.  alist lists the attachments.  list shows
them, ordered, in the headers.

> > Adding -attachformat 1 to the send entry of your .mh_profile
> > will get rid of the name and x-unix-mode.  That option can
> 
> The name is useful for actual attachments although we should really be
> using Content-Disposition for that.

We do, almost, with -attachformat 1.  We include filename in the
Content-Disposition of an attachment.  We also include name in the
Content-Type.  That seems to be common (mis-)usage.  And see below
about mhstore using the Content-Type name.

Here's an example with a plain text attachment, using -attachformat 1:

  --- =_aa0
  Content-Type: text/plain; charset="us-ascii"

  This is the body of my message;

  --- =_aa0
  Content-Type: text/plain; name="attachment.txt"; charset="us-ascii"
  Content-Disposition: attachment; filename="attachment.txt"

  Here are the contents of my text attachment.

  --- =_aa0--

> For the body, I can't understand why anyone would want either name
> or x-unix-mode.

mhstore ignores Content-Disposition.  If there's no name in
Content-Type, it generates a name based on the message
number.

David


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [really non-ASCII message bodies ]

[Ken Hornstein]

>That's what (as I understand it) Jon's patch handles (I still use the
>latest released version of nmh, which predates all this stuff ... there
>hasn't been a new release (since 1.3) for a long time now...) and makes a
>standards conforming message.

You know, this has been bugging me.  Should we cut a new release?  I kinda
think it's long-overdue.

I'm thinking that what we have now (modulo any autoconf cleanup, which
I've been itching to work on) should be 1.4, and whatever comes out of
this MIME discussion should be post-1.4.  Or do people want to include
this new MIME work?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ reallynon-ASCII message bodies ]

[Oliver Kiddle]

David Levine wrote:
> > These are definitely just wrong -- we shouldn't be specifying
> > name and x-unix-mode for the body text

Yes, that's badly wrong. I've never used -attach, one of the reasons being
that I didn't like it including x-unix-mode. Another thing that bothered
me was that I couldn't get it to apply the attachments but defer sending
so that I could run list to see the results. But I must admit that I
like the idea of not having to remember to type mime when my e-mail
contains attachments, or the odd umlaut or pound sign.

> Adding -attachformat 1 to the send entry of your .mh_profile
> will get rid of the name and x-unix-mode.  That option can

The name is useful for actual attachments although we should really be
using Content-Disposition for that. For the body, I can't understand
why anyone would want either name or x-unix-mode.

Oliver

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Ralph Corderoy]

Peter Maydell wrote:
> Ralph Corderoy wrote:
> > I agree.  I've never used -attach, instead sticking with
> > #-directives, and yet still send UTF-8 bodies with £ in text/plain
> > emails with no attachments by mistake.  This bug doesn't depend on
> > using -attach.
> 
> Yes. Perhaps we should make the condition be "do this if the incoming
> draft does not already have MIME headers" ? That way if the user has
> script-type solutions that pass an already-sensible draft to send we
> don't mess it up.

Good point.

Cheers,
Ralph.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Peter Maydell]

Ralph Corderoy wrote:
>Peter Maydell wrote:
>> (In fact I think we should go ahead and change the behaviour for
>> not-plain-ASCII bodies even if the user didn't pass the -attach
>> switch, but I'm guessing I might get argued down on that.)
>
>I agree.  I've never used -attach, instead sticking with #-directives,
>and yet still send UTF-8 bodies with =C2=A3 in text/plain emails with no
>attachments by mistake.  This bug doesn't depend on using -attach.

Yes. Perhaps we should make the condition be "do this if the
incoming draft does not already have MIME headers" ? That
way if the user has script-type solutions that pass an
already-sensible draft to send we don't mess it up.

>>  if (*p != '\t' && (*p >= 127 || *p < 32) {
>> non_ascii = 1;
>
>In that case, would plumping for character literals be nicer?
>
>if (*p < ' ' && *p != '\t' || *p > '~') {
>non_ascii = 1;

I don't care much either way on the style, I just want the logic
to be right.

(Also I'd just like to note that I had to manually edit out some
quoted-printable encoding before I could send this mail with nmh,
in a passing demonstration of our poor MIME handling :-))

-- PMM

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Ralph Corderoy]

Peter Maydell wrote:
> (In fact I think we should go ahead and change the behaviour for
> not-plain-ASCII bodies even if the user didn't pass the -attach
> switch, but I'm guessing I might get argued down on that.)

I agree.  I've never used -attach, instead sticking with #-directives,
and yet still send UTF-8 bodies with £ in text/plain emails with no
attachments by mistake.  This bug doesn't depend on using -attach.

>  if (*p != '\t' && (*p >= 127 || *p < 32) {
> non_ascii = 1;

In that case, would plumping for character literals be nicer?

if (*p < ' ' && *p != '\t' || *p > '~') {
non_ascii = 1;

Cheers,
Ralph.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [really non-ASCII message bodies ]

[Robert Elz]

In this discussion people (other than perhaps Jon, though he hasn't
said this explicitly) have just been assuming that if the e-mail body
of a message contains data that is not ascii, then it must be some other
character set, because after all, all e-mail is text ...

In the days of MIME, that's simply not true, and while it is unlikely
that anyone is going to use prompter, or even some other editor, to
produce a jpeg file, there's nothing to prevent a script producing a
file with a jpeg body, and 822 headers, and handing that to nmh to process.

We might prefer such a script to generate all the right headers, but MH
really doesn't like it if we attempt to tell it mime info in the
components file (or the draft) - it insists on adding that itself, so
not doing all the content type processing before calling nmh processes
is understandable.

Now there is nothing at all illegal about this - even ignoring that
"illegal" is the wrong word to use in any case, "non-conforming" would
be the correct term.   The standards don't apply to what the user feeds
nmh, that's locally defined "anything goes" territory.   What matters is
what nmh hands to the MTA (and even more, what the local MTA passes on
to its peer).   There if we simply send an 822 (old style, non-MIME) message
with arbitrary binary content we have a non-conforming message.

That's what (as I understand it) Jon's patch handles (I still use the
latest released version of nmh, which predates all this stuff ... there
hasn't been a new release (since 1.3) for a long time now...) and makes a
standards conforming message.   It obviously has no way of knowing what the
data that it detects as non-ascii is (or not without extra information from
the sender), so "application/octet-stream" sounds to me as if it is the
perfect choice (along with either QP or B64 encoding to handle the body
format) to indicate "here is stuff, but I have no idea what it means, work
it out for yourself" - which for many users of this kind of procedure
would probably be adequate.

I'm certainly not arguing that we should keep this behaviour, and certainly
not as the default - I expect that real users of binary message bodies that
are not text are so rare that, even if there are any at all, updating them
would not be a huge problem (provided the change notes for the next nmh
release make it clear this has happened).

However, I don't think we should give up the ability to simply send an
e-mail where the body is image/jpeg or whatever - there's no requirement that
there be any text in the body of the message at all, even though most MUA's
simply assume that, and require a multipart to include anything that is not
text.  MH should be better than that, being just as good as "most MUA's" is
a fairly grevious insult IMO.  And while retaining the # language of mhbuild,
or something equivalent, is essential to enable truly general messages to
be created, expecting to use that for trivial tasks is, I agree, asking too
much - and requiring explicit mime processing at the whatnow stage should
only be necessary when the full mhbuild procedure is to be invoked.
(Do recall that wnen this was added, MIME messages were rare, and lots of
users didn't like them - most MUA's had no way to display them, not even
as "good" as nmh does now - and so wanting that processing was very
unusual.  These days, almost every message should comply with at least
basic mime formats.

My suggestion to handle general bodies is to allow a switch that sets the
MIME content-type of the message (defaulting to text/plain) - and then base
all the other decisions off that.   If (as a result of the default, or by
being explicitly set) we get a text/* content-type, then we can attempt to
work out the charset involved, and add the proper indicator.  On the
other hand, if someone really wants to send an application/octet-stream,
then let's allow them to do that, or if they want to send image/jpeg or
audio/whatever they should be able to do that too (a message that is
entirely audio/* could even be handled my "show" by playing it through the
local system's speakers, assuming that's possible - implementing voice-email)

I also don't believe that this processing should be keyed off some -attach
switch - as a way to simplify adding an attachment to a message (incidentally,
if given twice, can we have two attachments, or is there some other way to
do that?) it sounds OK, but for charset processing?

For text messages, the right thing should be done regardless of whether there's
any plan or intent to add attachments, and using a switch "-attach" in the
profile to mean "encode my text correctly" is bizarre...

I'm all for backwards compatability, but only backwards compatible for
correct behaviour, keeping all the existing bugs should not be required
(though I think there are environments where even that is expected.)

Even for attachments, as I understand it, that's keyed off a pseudo-header
added to the components file (and so appears in th

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Ken Hornstein]

>> The current behavior was the best idea that I had
>> at the time and nobody has said anything about it until recently.  I don't
>> mind it changing, but I don't want to all of a sudden get complaints from
>> people who were counting on this behavior.
>
>Well, I always considered the current behaviour a bug, but I didn't say
>anything, because the nmh-way of software development seemed pretty 
>inefficient and I didn't want to look at the code myself either.

We have a "way" of software development?  When did that happen? :-)

In all seriousness ... what, exactly, do you mean?  I guess our current
way is, "Anyone who's interested, please contribute!".  I don't see how
that's really much different than other open-source packages.

Also, as long as we're on the subject ... if people want to submit patches
to the list, perhaps formatting them with git format-patch (since, hey,
I went to the whole trouble to convert everything to git) might be
worthwhile.  Or perhaps just doing that when everyone agrees on the
code would make things easier (because the patch could be processed with
git am).

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ reallynon-ASCII message bodies ]

[Lyndon Nerenberg]

On 10-12-07 3:48 PM, Jon Steinhart wrote:

This is the first that anybody has spoken
up about this as far as I'm aware, so I was trying to protect backward
compatibility.


A lot of MTAs just accept the stuff, even though it violates the 
standards. The assumption was 'just treat it as 8859-1'. That sort of 
worked long ago, but not any more.


Now that the whole email delivery chain has had to start dealing with 
character set encodings properly I've noticed a (very) slight increase 
in the number of sites that are rejecting un- and mis-encoded non-ASCII 
text.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ reallynon-ASCII message bodies ]

[Jon Steinhart]

If this is a bug that nobody has bothered with for years then by all
means go ahead and fix it.  This is the first that anybody has spoken
up about this as far as I'm aware, so I was trying to protect backward
compatibility.  No need to do that for bugs though.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Valdis . Kletnieks]

On Tue, 07 Dec 2010 12:03:38 CST, Earl Hood said:
> On Tue, Dec 7, 2010 at 11:10 AM, Jon Steinhart  wrote:
> > I understand that my attachment system does not handle non-ASCII message
> > bodies, but again, that's because non-ASCII message bodies are not "legal".
> 
> Please cite an RFC that says non-ASCII bodies are not legal.
> 
> With MIME, you have the Content-Transfer-Encoding field, which allows
> for 8bit.  And then, if you have a Content-Type type that supports
> charset parameter, you can "legally" have a body that is non-ASCII.

A MIME message that has a Mime-Version: and appropriate C-T-E: headers can
certainly be non-ASCII.  What's illegal is sending non-ASCII *without* such 
headers
(which is what nmh has been doing in the past).


pgpqGwTkJbOGo.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ reallynon-ASCII message bodies ]

[David Levine]

Peter wrote:

> markus schnalke wrote:
> >The old code generates ...
> >
> >... for ASCII:
> >
> >  Content-Type: text/plain; name="sendKi9x7j"; x-unix-mode="0644";
> >  charset="us-ascii"
> >  Content-ID: <4962.128958967...@argentina.foo>
> >  Content-Description:   ASCII text
> >
> >  foo
> >
> >... for non-ASCII (only if at least one attachment is present):
> >
> >  Content-Type: application/octet-stream; name="sendbRaV8T";
> >  x-unix-mode="0644"
> >  Content-ID: <5209.128958999...@argentina.foo>
> >  Content-Description:   UTF-8 Unicode text
> >  Content-Transfer-Encoding: base64
> >
> >  d2l0aCBKb24
>
> These are definitely just wrong -- we shouldn't be specifying
> name and x-unix-mode for the body text

Adding -attachformat 1 to the send entry of your .mh_profile
will get rid of the name and x-unix-mode.  That option can
also be added when entering send at the whatnow prompt.  The
send man page has examples of what it produces.

If there's consensus to make that the default, it would be an
easy code and documentation change.  (Yes, I'm volunteering
to make the changes.  But not to push for consensus :-)

> (and base64ing when we could q-p is a bit unfriendly).

Blackberries, and I think Droids, unnecessarily base64 text.
But I do agree with you, nmh shouldn't.

David

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[harald . geyer]

Jon Steinhart :
> The current behavior was the best idea that I had
> at the time and nobody has said anything about it until recently.  I don't
> mind it changing, but I don't want to all of a sudden get complaints from
> people who were counting on this behavior.

Well, I always considered the current behaviour a bug, but I didn't say
anything, because the nmh-way of software development seemed pretty 
inefficient and I didn't want to look at the code myself either. So,
when I found out that nmh was sending illegal mails (the timestamps of
my filesystem tell me it was 25. Jun 2008), I just "fixed" this
by adding three lines to the components file:

Content-Type: text/plain; charset="iso-8859-15"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

(which of course I have to remove if I actually want to attach a file
to a mail)

I guess, I'm not the only one silently applying some workaround but
I also guess that much more people unknowingly send illegal mail.
So unless somebody on this mailinglist states that he actually needs
the current behaviour, I think it is very safe to assume that no such
complaints you are fearing will ever be made.

Given the number of mails wasted on this seemingly obvious question now, I
really regret not filing a bug report 2.5 years ago.

BTW, I also use nmh exclusively for my mail, except for the two times/year
when I actually need to send signed/encrypted mails.

Personally I think that nmh should rather abort than silently sending illegal
mails.

Harald

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Peter Maydell]

markus schnalke wrote:
>[2010-12-07 12:33] Jon Steinhart 
>Examples for what gets generated from mail *body text*:

Thanks for doing this and saving me the effort ;-)

>The old code generates ...
>
>... for ASCII:
>
>  Content-Type: text/plain; name="sendKi9x7j"; x-unix-mode="0644";
>  charset="us-ascii"
>  Content-ID: <4962.128958967...@argentina.foo>
>  Content-Description:   ASCII text 
>
>  foo
>
>... for non-ASCII (only if at least one attachment is present):
>
>  Content-Type: application/octet-stream; name="sendbRaV8T";
>  x-unix-mode="0644"
>  Content-ID: <5209.128958999...@argentina.foo>
>  Content-Description:   UTF-8 Unicode text 
>  Content-Transfer-Encoding: base64
>
>  d2l0aCBKb24

These are definitely just wrong -- we shouldn't be specifying
name and x-unix-mode for the body text (and base64ing when
we could q-p is a bit unfriendly).

-- PMM

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

Jon, sorry for the harsh mail. I really had been in rage. :-/

In a recent mail, you said:

> The current behavior was the best idea that I had
> at the time and nobody has said anything about it until recently.

I really don't blame you for what we have; quite the opposite: I am
very gretaful for what we have.



[2010-12-07 22:45] markus schnalke 
> 
> I ask other people to take a look and express their opinion.

Thanks to everyone speaking up.


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

[2010-12-07 12:33] Jon Steinhart 
> Still trying to understand this.  Decided to finally look at the code instead 
> of
> relying on my fading memory.

:-) Thanks.


> The existing code takes a non-ASCII message body and sends it as an attachment
> of type application/octet-stream.
> 
> Your patch changes this behavior so that it is sent as type text/plain with 
> the
> appropriately chosen character set.

Both correct.

> In order to do this, you test the message body for non-ASCII characters in
> attach().  If you find any, you write an entry directly into the composition
> file instead of calling make_mime_composition_file_entry().

Correct.

> This is changing existing behavior if I understand it correctly.

Behavior in what gets generated, yes, but this is of need when fixing
things.

Examples for what gets generated from mail *body text*:

The old code generates ...

... for ASCII:

  Content-Type: text/plain; name="sendKi9x7j"; x-unix-mode="0644";
  charset="us-ascii"
  Content-ID: <4962.128958967...@argentina.foo>
  Content-Description:   ASCII text 

  foo

... for non-ASCII (only if at least one attachment is present):

  Content-Type: application/octet-stream; name="sendbRaV8T";
  x-unix-mode="0644"
  Content-ID: <5209.128958999...@argentina.foo>
  Content-Description:   UTF-8 Unicode text 
  Content-Transfer-Encoding: base64

  d2l0aCBKb24


With my patch such MIME parts are generated ...

... for ASCII:

  Content-Type: text/plain; charset="us-ascii"
  Content-ID: <5048.128958978...@argentina.foo>

  foo

... for non-ASCII:

  Content-Type: text/plain; charset="UTF-8"
  Content-ID: <5260.128959006...@argentina.foo>
  Content-Transfer-Encoding: quoted-printable

  Umlauts: =C3=A4 and =C3=B6 and =C3=BC.


The function make_mime_composition_file_entry() gives us nothing but
information we don't need/want (temp file names, file permissions) and
it definately does not use the best possible CT and CTE for the body
text.


> This is fine
> with me provided that users must explicitly enable the change using an option.

An option to activate a fix???


> Now that I'm actually looking at the code, I would suggest an option
> (choose a better name) of binary-body-content-type.  You could change the
> make_mime_composition_file_entry() line
> 
>   content_type = binary ? "application/octet-stream" : "text/plain";
> 
> to replace the "application/octet-stream" with the option value, or the 
> existing
> value as a default if the option is not specified.
> 
> A user wanting this behavior would have a profile entry of
> 
>   binary-body-content-type: text/plain
> 
> I think that this would be a simpler code change that would accomplish your 
> goal.

Sorry, but I really think you don't get the point. We don't need
config options if we already have the facilities to do it right
automatically. Why should any user need to tell nmh what content type
to use for the text he writes? The mhbuild facility can already find
out which is appropriate. My patch also divides between mail text and
attachments for which different things are relevant. Your comment
above does this not and would then use binary-body-content-type for
any non-ASCII attachment also.

I read your mails and ask myself if you really read what I write and
if you have had a look into the code we are talking about.

I very much value the work you did for nmh and you see that this patch
bases on what you created, but now it may be to point to either have a
close look at the problem and code or step back and let other people
talk. I do think you don't understand the situation and the relavant
code good enough (presumably due to lack of time).

Of course, I may be wrong. Currently, however, it rather seems to me
as if it's not me who is not understanding the whole thing. I really
spent much time in the code and doing tests. And I did my best
explaining everything.


I ask other people to take a look and express their opinion.


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Peter Maydell]

chad wrote:
>On Dec 7, 2010, at 12:48 PM, Ken Hornstein wrote:
>> You know  I'm all for backwards compatibility and everything, but
>> I'm wondering ... did the previous behavior actually make sense?  Can
>> people argue that it was desirable or correct?  Or was the previous
>> behavior actually wrong, and this is really fixing a long-standing
>> bug?  
>
>It was a bug.  The only suggesting that it wasn't a bug is instead saying 
>that it was `illegal' (which it wasn't... it just usually was a bad idea).

I agree; we should just change the behaviour here. (In particular
the previous behaviour would have differed in how it handled the
body depending on whether there was an attachment or not, which
suggests to me that it's just not a case anybody has cared about
before now.)

(In fact I think we should go ahead and change the behaviour for
not-plain-ASCII bodies even if the user didn't pass the -attach
switch, but I'm guessing I might get argued down on that.)

I do think the "is the body not plain ASCII?" check is not quite right.
I think that the presence of special characters (most notably ESC)
ought to also MIMEification. Otherwise we will not do the right thing
for Japanese character sets like shift-JIS. (Yes, I do care about this,
it's not just idle nitpickery.) I would suggest
 if (*p != '\t' && (*p >= 127 || *p < 32) {
non_ascii = 1;

ie encode unless it's in the printable ascii range or space or tab.

-- PMM

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[chad]

On Dec 7, 2010, at 12:48 PM, Ken Hornstein wrote:

> You know  I'm all for backwards compatibility and everything, but
> I'm wondering ... did the previous behavior actually make sense?  Can
> people argue that it was desirable or correct?  Or was the previous
> behavior actually wrong, and this is really fixing a long-standing
> bug?  

It was a bug.  The only suggesting that it wasn't a bug is instead saying 
that it was `illegal' (which it wasn't... it just usually was a bad idea).

nmh was used so infrequently in places that aren't 7-bit clean that none
of the people who noticed complained; they just binned it with the
host of non-i18n'd software and moved on.  This is generalizing a bit
from a small sample, but I'd be even more astonished than if we found
more than a dozen people who use mh exclusively for all their email. ;)

*Chad



___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

> >The existing code takes a non-ASCII message body and sends it as an 
> >attachment
> >of type application/octet-stream.
> >
> >Your patch changes this behavior so that it is sent as type text/plain with 
> >the
> >appropriately chosen character set.
> 
> You know  I'm all for backwards compatibility and everything, but
> I'm wondering ... did the previous behavior actually make sense?  Can
> people argue that it was desirable or correct?  Or was the previous
> behavior actually wrong, and this is really fixing a long-standing
> bug?  Because if we decide that the previous behavior is a bug, then
> I don't think an explicit enable option for this chance makes sense; I'd
> prefer that the new behavior be the default.
> 
> (I am personally on the fence regarding whether or not the previous
> behavior is a bug).
> 
> --Ken

Don't disagree with you.  The current behavior was the best idea that I had
at the time and nobody has said anything about it until recently.  I don't
mind it changing, but I don't want to all of a sudden get complaints from
people who were counting on this behavior.  Maybe that number is 0, but I
have no way of knowing.  I don't care that much, so if you think compability
isn't an issue here that's fine with me.

If the defalt behavior was to change I would add a "binary" flag to
make_mime_composition_file_entry() so that the body didn't have to be
scanned for non-ASCII characters twice.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Ken Hornstein]

>The existing code takes a non-ASCII message body and sends it as an attachment
>of type application/octet-stream.
>
>Your patch changes this behavior so that it is sent as type text/plain with the
>appropriately chosen character set.

You know  I'm all for backwards compatibility and everything, but
I'm wondering ... did the previous behavior actually make sense?  Can
people argue that it was desirable or correct?  Or was the previous
behavior actually wrong, and this is really fixing a long-standing
bug?  Because if we decide that the previous behavior is a bug, then
I don't think an explicit enable option for this chance makes sense; I'd
prefer that the new behavior be the default.

(I am personally on the fence regarding whether or not the previous
behavior is a bug).

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

Still trying to understand this.  Decided to finally look at the code instead of
relying on my fading memory.  Sorry if some of my earlier memory-based comments
were off-base.  Please let me know if my understanding of your proposed patch is
correct.

The existing code takes a non-ASCII message body and sends it as an attachment
of type application/octet-stream.

Your patch changes this behavior so that it is sent as type text/plain with the
appropriately chosen character set.

In order to do this, you test the message body for non-ASCII characters in
attach().  If you find any, you write an entry directly into the composition
file instead of calling make_mime_composition_file_entry().

This is changing existing behavior if I understand it correctly.  This is fine
with me provided that users must explicitly enable the change using an option.

Now that I'm actually looking at the code, I would suggest an option
(choose a better name) of binary-body-content-type.  You could change the
make_mime_composition_file_entry() line

content_type = binary ? "application/octet-stream" : "text/plain";

to replace the "application/octet-stream" with the option value, or the existing
value as a default if the option is not specified.

A user wanting this behavior would have a profile entry of

binary-body-content-type: text/plain

I think that this would be a simpler code change that would accomplish your 
goal.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Ralph Corderoy]

Hi,

markus schnalke wrote:
> > BTW, I would suggest using isascii() rather than (*p > 127 || *p < 0).
> 
> I just kept what you once wrote. ;-P
> But, yes, you are right.

Given it's `char *p' then *p may be unsigned on some systems, e.g. ARM,
and a compiler could warn on testing if it's negative so isascii() is
much nicer.  :-)

Cheers,
Ralph.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Earl Hood]

On Tue, Dec 7, 2010 at 11:10 AM, Jon Steinhart  wrote:
> I understand that my attachment system does not handle non-ASCII message
> bodies, but again, that's because non-ASCII message bodies are not "legal".

Please cite an RFC that says non-ASCII bodies are not legal.

With MIME, you have the Content-Transfer-Encoding field, which allows
for 8bit.  And then, if you have a Content-Type type that supports
charset parameter, you can "legally" have a body that is non-ASCII.

Note, way back when MIME was first defined, it was probably not good
practice to use 8bit CTE since MTAs were not friendly with 8bit data,
but today, that is less likely.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

[2010-12-07 09:10] Jon Steinhart 
> > [2010-12-07 08:27] Jon Steinhart 
> > > Sounds good.  Is the patch that you sent out complete?  I don't see an 
> > > option
> > > that enables/disables this behavior and I think that there should be one.
> > 
> > I believe it's correct that there is no switch.
> > 
> > If one wants to deactivate it, do not specify -attach.
> > 
> > If -attach is given, I believe the changes are fixes for broken
> > behavior. Your attachment system lacks some awareness for non-ASCII
> > text, which you probably don't deal with much. This is improved with
> > my patch.
> 
> OK.  I think that there should be a switch.  I guess it bugs me to see the
> character-by-character examination of the message body on by default.

The char-by-char examination is ugly, yes.


> I understand that my attachment system does not handle non-ASCII message
> bodies, but again, that's because non-ASCII message bodies are not "legal".
> I think that you have justified extending nmh to handle "illegal" message
> bodies.  I'm just nitpicking on the implementation details.

With MIMEification, they are legal.

I want nmh to convert illegal draft messages to legal messages.
Currently nmh sends illegal messages if the user composes such ones.
With my patch nmh cares to only send legal messages. Programs should
support humans if possible.


> Could you please explain again how you get the character set information
> for non-ASCII message bodies?  Sorry that I didn't save your original
> message on this.  I seem to recall that you got it from the profile; I
> would rather see you get this from the LANG environment variable.

I just leave it up to buildmimeproc to find out. :-) We don't need to
do it at several places. I only say it's text/plain but nothing about
the encoding.

The man page of mhbuild(1) writes:

If a text content contains any 8-bit characters (characters with the
high bit set) and the character set is not specified as above,  then
mhbuild will  assume  the character  set  is  of  the type given by
the environment variable MM_CHARSET.  If this environment variable is
not set, then the character set will  be  labeled  as “x-unknown”.

If  a  text  content  contains  only 7-bit characters and the
character set is not specified as above, then the character set will
be labeled as “us-ascii”.

This information probably is outdated, but generally it hits the
point, probably the code is already better (in respect to MM_CHARSET).


> BTW, I would suggest using isascii() rather than (*p > 127 || *p < 0).

I just kept what you once wrote. ;-P

But, yes, you are right.


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

> [2010-12-07 08:27] Jon Steinhart 
> > Sounds good.  Is the patch that you sent out complete?  I don't see an 
> > option
> > that enables/disables this behavior and I think that there should be one.
> 
> I believe it's correct that there is no switch.
> 
> If one wants to deactivate it, do not specify -attach.
> 
> If -attach is given, I believe the changes are fixes for broken
> behavior. Your attachment system lacks some awareness for non-ASCII
> text, which you probably don't deal with much. This is improved with
> my patch.
> 
> meillo

OK.  I think that there should be a switch.  I guess it bugs me to see the
character-by-character examination of the message body on by default.

I understand that my attachment system does not handle non-ASCII message
bodies, but again, that's because non-ASCII message bodies are not "legal".
I think that you have justified extending nmh to handle "illegal" message
bodies.  I'm just nitpicking on the implementation details.

Could you please explain again how you get the character set information
for non-ASCII message bodies?  Sorry that I didn't save your original
message on this.  I seem to recall that you got it from the profile; I
would rather see you get this from the LANG environment variable.

BTW, I would suggest using isascii() rather than (*p > 127 || *p < 0).

Thanks,
Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

[2010-12-07 08:27] Jon Steinhart 
> Sounds good.  Is the patch that you sent out complete?  I don't see an option
> that enables/disables this behavior and I think that there should be one.

I believe it's correct that there is no switch.

If one wants to deactivate it, do not specify -attach.

If -attach is given, I believe the changes are fixes for broken
behavior. Your attachment system lacks some awareness for non-ASCII
text, which you probably don't deal with much. This is improved with
my patch.


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

Sounds good.  Is the patch that you sent out complete?  I don't see an option
that enables/disables this behavior and I think that there should be one.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

Hoi,

discussing these things hadn't been easy sometimes, but the points and
arguments became clear and now we reached some kind of consensus. For
me, the discussion had been worthwhile.


[2010-12-03 11:33] Jon Steinhart 
> 
>  o  Nobody objects to markus addressing this issue.  The objections are that
> his implementation breaks things, and handling illegal body content is
> not a compelling enough reason for breaking things.

> So, I think that enough has been said on this topic.  markus, can you outline
> for us an implementation that doesn't break things?  I think that everyone 
> will
> bless your changes if you do.

I agree with you here. Hence I created a new patch that concentrates
on the fourth case, explained in the other mail. AFAIS it does not
break anything.

Let me explain:

As it only modifies your attachment system now, everything is the same
if -attach is not specified.

For -attach being specified, the situation is such:

  no attachment hdr  +  body contains only ASCII  ->  sent as is
  attachment hdr +  body contains only ASCII  ->  MIMEified
  attachment hdr +  body contains non-ASCII   ->  MIMEified
  no attachment hdr  +  body contains non-ASCII   ->  MIMEified

The fourth case is different.

Additionally, the body text will be sent with a correct mime-type in
any case. Currently it was sent as application/octet-stream in the
third case.


The relation to `mime' at the whatnow prompt:

One surely wants to unset automimeproc when using -attach.

Running `mime' at the whatnow prompts is usually not needed as Jon's
attachment system handles it automatically.

Collisions only occure if an attachment header is present in the mail
and one runs `mime' at the whatnow prompt. If the body text contains
non-ASCII chars or not is irrelevant, it works as expected in both
cases.

As long as one does not add attachment headers to a specific draft,
one is able to use any mhbuild directives (/^#/) when running `mime'
at the whatnow prompt afterwards.


Further work:

The documentation currently does not cover my changes. Not much to
change, and I like to do that if the proposed changes are accepted.

More complex MIME structures than ``text followed by attachments'' are
not possible with Jon's attachment system. (Like they are not with
most MUAs.) One needs to create them with mhbuild directives and run
`mime' manually. (For forwarding messages, see below.)

Jon's attachment system still needs mhshow-suffix- entries or it will
be really dumb. This is something that should be covered separately,
maybe by a conceptional redesign (automatic detection, mailcap, ...).

Forwarding messages in MIME format could be added to Jon's system in a
way similar to what I proposed initially. I believe this would be
possible without breaking stuff. We would need to add -attach to
forw(1).


meillo


> P.S.  I'm trying to honor the way that you're name appears in your mail 
> header.
>   Do you really want it to be "markus" or should it be "Markus"?

Usually, I prefer ``meillo'' because that's a nearly unique
identifier. If you want to use my real name, I don't care if you spell
it in lower-case or with capital `M'. More important is honoring my
work by mentioning my name in the ChangeLog or commit messages. ;-)

diff --git a/uip/sendsbr.c b/uip/sendsbr.c
index 57ef007..8f5f2e1 100644
--- a/uip/sendsbr.c
+++ b/uip/sendsbr.c
@@ -196,6 +196,7 @@ attach(char *attachment_header_field_name, char *draft_file_name,
 int			c;			/* current character for body copy */
 int			has_attachment;		/* draft has at least one attachment */
 int			has_body;		/* draft has a message body */
+int			non_ascii;		/* msg body contains non-ASCII chars */
 int			length;			/* length of attachment header field name */
 char		*p;			/* miscellaneous string pointer */
 
@@ -228,29 +229,36 @@ attach(char *attachment_header_field_name, char *draft_file_name,
 	if (strncasecmp(field, attachment_header_field_name, length) == 0 && field[length] == ':')
 	has_attachment = 1;
 
-if (has_attachment == 0)
-	return (DONE);
-
 /*
- *	We have at least one attachment.  Look for at least one non-blank line
- *	in the body of the message which indicates content in the body.
+ * Check if body contains at least one non-blank char (= not empty)
+ * and if it contains non-ASCII chars (= need MIME).
+ * We MIMEify the message also if the body contains non-ASCII text.
  */
 
 has_body = 0;
+non_ascii = 0;
 
 while (get_line() != EOF) {
 	for (p = field; *p != '\0'; p++) {
-	if (*p != ' ' && *p != '\t') {
+	if (*p != ' ' && *p != '\t')
 		has_body = 1;
+	if (*p > 127 || *p < 0) {
+		non_ascii = 1;
 		break;
 	}
 	}
-
-	if (has_body)
+	if (non_ascii)
 	break;
 }
 
 /*
+ * Bail out if there are no attachments and only ASCII text.
+ * This means we don't need to convert it to MIME.
+ */
+if (!has_attachment && non_ascii == 0)
+	return (DONE);

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> Do you think that the then taken conceptual decisions will be correct
> forever? One thing I learned from, what you call the Linux way of
> doing 'software development' is that later you'll always know better
> and hence you should change. Nothing remains the same.
> 
> Note that I do not declare that I know better than you how to do
> everything, but I think about change and how better concepts could
> look like.

What I see happening in what I call the generalized Linux community
today is an infinite number of monkeys throwing spaghetti at the wall,
and absolutely everything that sticks geting shipped.  As I alluded to
in an earlier message today, I suspect this comes from the perception
that 'my desktop is the universe' and therefore what works for me just
works.  People don't grasp the consequences their changes will have on
others.

The one-person one-desktop metaphor is a fact of life, and somehow our
current models of software distribution will have to adapt to that.
But it ain't going to happen with MH ;-) So, despite a wickedly
interesting new research problem, the legacy of three+ decades of
in-place software that uses MH isn't going to go away.  If there is to
be an nmh2 (horrible name, BTW), it should learn from MH and then
divorce itself from it in the same way that Plan 9 escaped from UNIX.

--lyndon


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Michael Richardson]

> "heymanj" == heymanj   writes:
>> Joel Uckelman  writes:
>>> Thus spake Lyndon Nerenberg:
 I would be surprised (stunned, really) if anyone was still
 using MH *exclusively* as their MUA.
>>> Right here. Be surprised.
>> Mee too.
>> 
>> Norman Shapiro

heymanj> As long as I get to count xmh, exmh, and sylpheed gui
heymanj> interfaces, then I've been using exclusively since testing
heymanj> it for IBM's AIX v 2.2 (1988)

The word is "exclusively" --- yeah, I use mh-e, 90% of the time...
but I regularly use pick, folder, refile, next, from the command line.
And I use nmh to maintain mail archives on other machines (servers)...

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Peter Maydell]

Jon Steinhart wrote:
>Let me try to summarize here because there seems to be lots of energy here
>for commentary but little for things that move us forward:
>
> o  Many people still exclusively use nmh, some have drifted away.  'Nuf said
>on this topic.
>
> o  There is a general concensus that backward compatibility is important and
>that changes shouldn't break things unless there is a compelling reason.
>
> o  The particular thing that markus and Ralph want to address is how illegal
>body content is handled.  Fixing this would be convenient.

Yes, I want this fixed too, and I have an opinion on how it should be fixed.

> o  markus is willing to write code.  Cool!
>
> o  Nobody objects to markus addressing this issue.  The objections are that
>his implementation breaks things, and handling illegal body content is
>not a compelling enough reason for breaking things.
>
> o  At least one suggestion (mine) has been floated on a way to implement this
>in a way that does not break things.

Two suggestions -- mine as well. I think it's mostly complementary to
yours rather than at cross purposes, some of the aspects it's fixing
are different.

-- PMM

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

> markus schnalke wrote:
> > (4) no attachments & non-ASCII -> no MIME; the message contains
> > non-ASCII chars; the recipient can not know which charset the
> > non-ASCII chars had been.
> > 
> > To cover case 4, one needs to run mime at the whatnow prompt manually.
> 
> Yes, and I find that annoying.  Most of the time I want to sent non-MIME
> ASCII emails and I do that just fine.  Sometimes my English email will
> mention money, £42, and if I forget to "mime" at whatnow I send a broken
> email.  So far, markus' approach of catching this fourth case sounds
> good.  What's currently happening is wrong AFAICS.
> 
> Cheers,
> Ralph.

Let me try to summarize here because there seems to be lots of energy here
for commentary but little for things that move us forward:

 o  Many people still exclusively use nmh, some have drifted away.  'Nuf said
on this topic.

 o  There is a general concensus that backward compatibility is important and
that changes shouldn't break things unless there is a compelling reason.

 o  The particular thing that markus and Ralph want to address is how illegal
body content is handled.  Fixing this would be convenient.

 o  markus is willing to write code.  Cool!

 o  Nobody objects to markus addressing this issue.  The objections are that
his implementation breaks things, and handling illegal body content is
not a compelling enough reason for breaking things.

 o  At least one suggestion (mine) has been floated on a way to implement this
in a way that does not break things.

So, I think that enough has been said on this topic.  markus, can you outline
for us an implementation that doesn't break things?  I think that everyone will
bless your changes if you do.

Jon

P.S.I'm trying to honor the way that you're name appears in your mail 
header.
Do you really want it to be "markus" or should it be "Markus"?

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Ralph Corderoy]

John Romine wrote:
> ...I dist the message to my Gmail account.  (Before Gmail, I was
> dist'ing to another mailbox that I POP'd with Thunderbird on a Windows
> PC.)  I haven't found a dist command in Gmail or Thunderbird; if you
> know of one, let me know.

No, I don't know of one but have you found Gmail doesn't display the
Resent-* headers, even though they're in the RFCs dating back yonks?  If
there's anyone on the list with links to the Gmail folks please give
them a prod.  I raised it through the normal "I'm a plebby user" channel
years ago with no effect.  They surely should comply with the RFCs where
it's easy to do?

Cheers,
Ralph.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Ralph Corderoy]

markus schnalke wrote:
> (4) no attachments & non-ASCII -> no MIME; the message contains
> non-ASCII chars; the recipient can not know which charset the
> non-ASCII chars had been.
> 
> To cover case 4, one needs to run mime at the whatnow prompt manually.

Yes, and I find that annoying.  Most of the time I want to sent non-MIME
ASCII emails and I do that just fine.  Sometimes my English email will
mention money, £42, and if I forget to "mime" at whatnow I send a broken
email.  So far, markus' approach of catching this fourth case sounds
good.  What's currently happening is wrong AFAICS.

Cheers,
Ralph.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Ralph Corderoy]

Lyndon Nerenberg wrote:
> I would be surprised (stunned, really) if anyone was still using MH 
> *exclusively* as their MUA.  I haven't done so for years.

I'm another one that does use it exclusively and have done since the
early 1990s.

> But the solution is not to turn it into a python-based rewrite of
> Evolution.

I realise some of us are very attached to our MUA, and those of us that
use it exclusively have even more reason to be!, but I'm glad markus and
the others are raising issues rather than just have nmh languish.  Yes,
a fork may be one of the right choices for some of these newer ideas and
nmh shouldn't break backwards compatibility willy-nilly, but the
conversation shouldn't be curtailed needlessly.

Cheers,
Ralph.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[John Romine]

On Fri, Dec 3, 2010 at 9:35 AM, Ken Hornstein  wrote:

> >Well, since you asked, I am still using MH 6.8.4 on Solaris, often with
> >exmh.  I'm also running vintage MMDF as my MTA :-).
>
> Hey John, cool to see you're still around!  Hadn't seen anything from
> you in forever, so I thought you had gone off to bigger and better
> things.
>

I'm still at UC Irvine, in the School of Engineering since 1999. Lately I'm
doing a lot of web applications in PHP and websites in Drupal.

 >However, I'm also using Gmail, particularly because of its threading and
> >spam-rejection, and also because people mail me documents so often
> >(and Gmail provides a good in-browser preview).
>
> Just for my own curiousity (and having a better desire to understand how
> people use MH/nmh), how exactly does this work?  Do you preview email via
> the Gmail web interface and then suck it down via MH?  What tools do you
> use to do that, since I'm not sure that stock MH 6.8.4 can do that out
> of the box?
>

My UCI mail goes to MH first (maildelivery hooks copy the mail to an
archive file, and filter mailing list messages into various folders).
If I get an attachment that I can't handle easily on Solaris, I dist the
message to my Gmail account.  (Before Gmail, I was dist'ing to another
mailbox that I POP'd with Thunderbird on a Windows PC.)  I haven't found
a dist command in Gmail or Thunderbird; if you know of one, let me know.

The biggest change for me personally is using a Windows laptop.  If
I'm not at my Solaris desktop, displaying non-text content (over my
putty/ssh connection) is more challenging.  When I get mailed a
URL, I have to cut/paste it into Firefox (on the laptop).  I sometimes
use NX (nomachine.com) or Cygwin-X, but its often easier to just view
the content directly on the laptop.  Gmail (or Thunderbird) makes clicking
on URLs trivial.

I've started using Gmail as my primary mailbox for my LA Drupal-related
mail, since it doesn't need to be stored on my UCI server and the spam-
rejection is more necessary.

John
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Anders Eriksson]

> Do an MH-like plug-in for Tbird/Mozilla/etc ?

If I read this right, that work is already underway:
https://bugzilla.mozilla.org/show_bug.cgi?id=402392

-Anders

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[heymanj]

On 2 December 2010 at 14:25, n...@dad.orgwrote:

>Joel Uckelman  writes:
>>Thus spake Lyndon Nerenberg:
>>>
>>> I would be surprised (stunned, really) if anyone was still using MH
>>> *exclusively* as their MUA.
>>
>>Right here. Be surprised.
> 
> Mee too.
> 
> Norman Shapiro

As long as I get to count xmh, exmh, and sylpheed gui interfaces, then 
I've been using exclusively since testing it for IBM's AIX v 2.2 (1988)

jerry
   //  Jerry Heyman   | "Congress does not draw to its halls
  //   Amiga Forever :-)  | those who love liberty, it draws those
  \\ //heymanj at acm dot org | who love power." Judge Andrew Napolitano
   \X/ http://www.hobbeshollow.com

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[norm]

Joel Uckelman  writes:
>Thus spake Lyndon Nerenberg:
>>
>> I would be surprised (stunned, really) if anyone was still using MH
>> *exclusively* as their MUA.
>
>Right here. Be surprised.

Mee too.

Norman Shapiro
798 Barron Avenue
Palo Alto CA 94306-3109
(650) 565-8215
n...@dad.org

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[norm]

"Lyndon Nerenberg (VE6BBM/VE7TFX)"  writes:
>> It seems to me as if you would be doing compatibility for
>> compatibility's sake. This is sticking to old cruft. Caring to much
>> for some old userbase likely keep you from getting new users while old
>> ones slowly vanish.
>
>Why do we need new users?  When did this become a popularity contest?
>
>MH was written by and for people who have a deep understanding of how email
>works

Not so. MH was written BY such people, but cetainly not FOR such people.

Norman Shapiro
798 Barron Avenue
Palo Alto CA 94306-3109
(650) 565-8215
n...@dad.org

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

> Probably parts of what I said were ``lost in translation'' as English
> is not my native language.
> 
> 
> I explain again what I meant:
> 
> Using non-ASCII chars in the mail *body* together with Jon's
> attachment system leads to the following cases:
> 
> (1) no attachments & only ASCII -> no MIME; everything well
> 
> (2) attachments & only ASCII -> MIME; everything well
> 
> (3) attachments & non-ASCII -> MIME; everything well
> 
> (4) no attachments & non-ASCII -> no MIME; the message contains
> non-ASCII chars; the recipient can not know which charset the
> non-ASCII chars had been.
> 
> To cover case 4, one needs to run mime at the whatnow prompt manually.
> 
> 
> meillo

Actually, I think that I figured that out.  Maybe you haven't gotten through
the stack of emails yet.  The summary is:

 1.  The #4 case is not "legit" in rfc-land.  That doesn't mean that it wouldn't
 be a good idea to add convenience functionality.

 2.  I suggested an alternate way to do this which I think is simpler, doesn't
 break anything, and works from the LANG environment variable so that the
 charset information wouldn't have to be configured on a per-user basis.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[markus schnalke]

Probably parts of what I said were ``lost in translation'' as English
is not my native language.


I explain again what I meant:

Using non-ASCII chars in the mail *body* together with Jon's
attachment system leads to the following cases:

(1) no attachments & only ASCII -> no MIME; everything well

(2) attachments & only ASCII -> MIME; everything well

(3) attachments & non-ASCII -> MIME; everything well

(4) no attachments & non-ASCII -> no MIME; the message contains
non-ASCII chars; the recipient can not know which charset the
non-ASCII chars had been.

To cover case 4, one needs to run mime at the whatnow prompt manually.


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really -attach ]

[Mike O'Dell]

"Isn't this just reimplementing mailcap?"

talk about irony...

when Nathaniel Borenstein first implemented the
first mime library and mailcap when he was at
Bellcore, the first mail software to us it was - MH!

  -mo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Valdis . Kletnieks]

On Thu, 02 Dec 2010 19:18:30 +0100, markus schnalke said:

> My patch however does break compatibility if one likes to send
> messages that contain non-ASCII chars without MIME.

Sending non-ASCII without MIME is against the RFCS, and shouldn't
be allowed.  This is one case where intentionally breaking compatibility
isn't a bad thing. (At a minimum, if it's a one-part mail, you need to at
least stick a MIME-Version: on it and a Content-Transfer-Encoding: 8bit
and hope the MTA is happy with that...)


pgp8EbYi1ft8H.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

> On Thu, Dec 2, 2010 at 12:42 PM, Jon Steinhart wrote:
> > Correct me if my memory is failing me here, I'm being lazy and not rereading
> > rfcs at the moment because I have other things to do.
> >
> > I recall that in the absence of appropriate headers messages are defined as
> > ASCII.  If that's the case, it strikes me that you're "fixing" something 
> > that
> > is convenient for you but technically not broken.
> 
> In the ideal world, what you have stated is true.  However, in the
> real world, in non-English locales, character data occurs in
> headers that not encoded according to MIME rules.
> 
> In my Perl app, I added an option to specify what is the default
> character encoding to assume for non-encoded data.  The default
> value is us-ascii (as the rfcs state), but the user can change
> it to something else.
> 
> Not sure if nmh needs something similar, but if there are
> users in non-English locales that have messages with non-English
> non-encoded data in header fields, then allowing to specify
> a default encoding to assume may be of use.
> 
> --ewh

I believe that that was what I was suggesting, in a don't-break-anything way.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Earl Hood]

On Thu, Dec 2, 2010 at 12:42 PM, Jon Steinhart wrote:
> Correct me if my memory is failing me here, I'm being lazy and not rereading
> rfcs at the moment because I have other things to do.
>
> I recall that in the absence of appropriate headers messages are defined as
> ASCII.  If that's the case, it strikes me that you're "fixing" something that
> is convenient for you but technically not broken.

In the ideal world, what you have stated is true.  However, in the
real world, in non-English locales, character data occurs in
headers that not encoded according to MIME rules.

In my Perl app, I added an option to specify what is the default
character encoding to assume for non-encoded data.  The default
value is us-ascii (as the rfcs state), but the user can change
it to something else.

Not sure if nmh needs something similar, but if there are
users in non-English locales that have messages with non-English
non-encoded data in header fields, then allowing to specify
a default encoding to assume may be of use.

--ewh

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really -attach ]

[Peter Maydell]

Jon Steinhart wrote:
>Well, I really don't want to do it at runtime because of my personal 
>preferences.
>For example, I have a zillion image viewers on my system but there is one that 
>I
>prefer for my mail.  I would hate to have the viewer magically change on me.

That's OK, we can do what mutt does and let the user say "use
my personal mailcap instead of/in addition to the system one".
Basically my point is that this is a solved problem and we
should be making sure nmh works with it, not reinventing our
own approach which will never be as good or well integrated
with the other parts of the OS/distro.

-- PMM

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really -attach ]

[Jon Steinhart]

> Jon Steinhart wrote:
> > 2.  Create a program a la configure that scans a target system for programs
> > that handle content and build the mhshow stuff automatically.  This
> > can't be hardwired because different things are available on different
> > target systems.
> 
> Isn't this just reimplementing mailcap? You want to read it at runtime,
> incidentally, because mailcap can be updated as new viewer programs are
> installed. Doing anything at configure time that asks "what binaries are
> installed" is a bad idea because for packages built by distros the answer
> will be "very little in the build environment" and package users could
> have anything at all.
> 
> -- PMM

Well, I really don't want to do it at runtime because of my personal 
preferences.
For example, I have a zillion image viewers on my system but there is one that I
prefer for my mail.  I would hate to have the viewer magically change on me.

I said "a la configure", not "configure".  I was thinking that this could be a
step run as part of install-mh that made some guesses and prompted users when
choices were available.  My notion here was to make it easier for first time
users to get started.

Another approach for this might be to have "fallbacks".  My guess is that 
install-mh
could preload a whole mess of mhshow-suffix stuff as these have more or less 
settled
out over time.  If the mhshow-show stuff could list multiple applications for a 
type
and choose the first one found then that stuff could also be preloaded into the
initial .mh_profile by install-mh.

I'm not the best person to be figuring out how to do this because it isn't a 
problem
for me.  I'm just trying to suggest approaches to addressing some of marcus's 
issues.
In a compatible way, of course :)

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really -attach ]

[Peter Maydell]

Jon Steinhart wrote:
> 2.  Create a program a la configure that scans a target system for programs
> that handle content and build the mhshow stuff automatically.  This
> can't be hardwired because different things are available on different
> target systems.

Isn't this just reimplementing mailcap? You want to read it at runtime,
incidentally, because mailcap can be updated as new viewer programs are
installed. Doing anything at configure time that asks "what binaries are
installed" is a bad idea because for packages built by distros the answer
will be "very little in the build environment" and package users could
have anything at all.

-- PMM

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really non-ASCII message bodies ]

[Jon Steinhart]

> English is probably your native language and the one your emails are
> written in.
> 
> This way non-ASCII text does not get handled specially (if no
> attachment is present).
> 
> No MIMEification means that the characters are plainly in the mail
> body. The original charset is not available in the mail which will
> lead to broken or wrong charcters display on systems with a
> non-compatible native charset.
> 
> Also the mail message is 8bit then.
> 
> Fixing this problem is part of my patch. @Jon: This actually can be
> considered as some kind of usage bug of your system. If you include
> non-ASCII text but no attachments then you need to run mime at whatnow
> prompt manually, otherwise you must not.
> 
> My patch however does break compatibility if one likes to send
> messages that contain non-ASCII chars without MIME.

Correct me if my memory is failing me here, I'm being lazy and not rereading
rfcs at the moment because I have other things to do.

I recall that in the absence of appropriate headers messages are defined as
ASCII.  If that's the case, it strikes me that you're "fixing" something that
is convenient for you but technically not broken.

I think that I now understand what you want, which is to be able to do a simple
"comp" and have things work automatically with non-ASCII message bodies without
having to mess around with mhbuild and all.

I'm going to keep harping on the "don't break things" theme, because it seems
like the goal should be to make things more convenient for you without making
things less convenient for others.

Would you consider leaving the -attach stuff as it is and adding a
-assume_non_ascii_is_in_the_charset_defined_by_the_lang_environment_variable
option instead?  Fine with me if you use a shorter name :)

Doing it this way doesn't break existing code, and makes the behavior optional
so that it won't surprise anybody who hasn't explicitly enabled it.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-02 12:40] David Levine 
> 
> Another data point:  I use nmh exclusively as my MUA.
> 
> Also, I haven't used mhbuild (mime at the whatnow prompt) since
> I started using -attach.  It's very easy to use and it certainly
> does work well.

English is probably your native language and the one your emails are
written in.

This way non-ASCII text does not get handled specially (if no
attachment is present).

No MIMEification means that the characters are plainly in the mail
body. The original charset is not available in the mail which will
lead to broken or wrong charcters display on systems with a
non-compatible native charset.

Also the mail message is 8bit then.

Fixing this problem is part of my patch. @Jon: This actually can be
considered as some kind of usage bug of your system. If you include
non-ASCII text but no attachments then you need to run mime at whatnow
prompt manually, otherwise you must not.

My patch however does break compatibility if one likes to send
messages that contain non-ASCII chars without MIME.


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[David Levine]

meillo wrote:

> Hmm that's then the basic point where we differ. I do care if the
> inside is clean and I rather like to remove features than add ones.
> From my point of view these are key factors to maintainability and
> thus for the future of the code. One of the most important properties
> of software is the question if the concepts are most simple and
> implemented best possible. If at some time the concepts are found to
> be imperfect, I really favor for change.

> I admit that providing a drop-in replacement is a fully valid goal. I
> rather dislike the fact that this looking back holds us from going
> forward. (It's more a general problem, though.)

Then it's time to fork.  Especially given that the current code
base has changed surprisingly (to me) little in the last decade
or so.  It might not be pretty but it works, at least well
enough to get used often.

While maintenance is painful, that doesn't happen very often.
And the intricate dependencies of people and frontends on nmh
restrict the kinds of changes that can reasonably be made.  For
example, while I don't use many, or even most, of nmh's
features, I think it would be a really bad idea to remove any of
them.

I could see an argument for starting over from scratch, but it's
clear that not enough people have enough spare time for that.

Another data point:  I use nmh exclusively as my MUA.

Also, I haven't used mhbuild (mime at the whatnow prompt) since
I started using -attach.  It's very easy to use and it certainly
does work well.

David

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [ really -attach ]

[Jon Steinhart]

> > Maybe I don't understand your proposed changes.  Apologies if I get this 
> > wrong;
> > I didn't save a copy of your original email and the archives are currently 
> > down.
> > 
> > There are currently -attach options on send and whatnow to support the 
> > non-standard
> > attachment header.  I don't even think about this because my .mh_profile 
> > includes:
> > 
> > send: -alias aliases -attach X-MH-Attachment
> > whatnow: -attach X-MH-Attachment
> > 
> > My understanding is that your change would be to remove the -attach options 
> > and to
> > have the .mh_profile include something like this instead:
> > 
> > attach: X-MH_Attachment
> 
> That's only the minor change I made (in order to enable any program to
> take part without the need to add the -attach switch to all of them).
> I did it because it reduces overall complexity and simplifies the
> configuration (which currently is very complex; you can hardly use nmh
> without spending weeks in setting everything up once).
> 
> This change, AFAIS, only breaks with the versions since you added your
> attachment system and only in the way that the -attach switch is not
> recognized. One hardly wants to define some non-standard attachment
> header anyways, therefore my version adds a default one. The
> attachment format needs to be specified differently if one likes to
> change it.
> 
> Where compatibility does get broken is that my attachment system would
> always be active, while your's by default would not. But that's the
> crucial point!
> 
> As I said above, currently nmh can hardly be used (for modern emailing,
> that people probably like to do) with the default setup. Everyone of
> us, of course has his rather complex setup which does what he likes,
> so you don't see this problem anymore. I needed about two month until
> nmh had been well configured. This included Jerry Peek's book or
> course, the man pages and the pretty old FAQ. I needed lots of time to
> figure out all the stuff. You often don't know if it is broken or if
> you just haven't found out where you need to configure what.

OK.  You raise an interesting point here, but I still think that there are
better ways to address it.

I want to point out that the reason that I did it the way that I did was
because the attachment header is NON STANDARD.  I wanted to make sure that
I didn't break anything.

I didn't have your issues in setting up nmh.  It worked out of the box.
It was way easier than competing mail systems and easier than most gui
systems.  The thing that took time was setting up all of the mhshow stuff
for each mime type.

So two suggestions:

 1.  Add the -attach options for send and whatnow in the default profile
 created by install-mh.  Keeps casual users from having to deal with
 it and doesn't break anything.

 2.  Create a program a la configure that scans a target system for programs
 that handle content and build the mhshow stuff automatically.  This
 can't be hardwired because different things are available on different
 target systems.

> Hence I would like to see nmh do the most likely thing per default.
> This for instance includes converting foreign charsets to the native
> one on show. This also includes the definition of the attachment
> header. I asked myself why a user or system administrator should need
> to set it manually. I fould no answer besides some corner cases where
> the behavior would change.
> 
> If no such header is present and all text is ASCII then the behavior
> is the original.
> 
> If a header is present or non-ASCII is used then the message is
> MIMEified. This very likely is what is intended.  For sending
> non-ASCII text without MIME I don't know. My patch MIMEifies in any
> case if it's non-ASCII.
> 
> Therefore my patch removes the need to run `mime' at the whatnow
> prompt. Why does the user need to decide if he needs MIME or not?
> Mostly he does not know an will MIMEify always. Then plain ASCII
> messages are MIMEified too which is not necessary. My patch does the
> more reasonable thing.
> 
> Further more it does not require the user to know about mhbuild(1)
> directives and makes /^#/ non-special (that's what your system
> provided). Running mime at the whatnow prompt to early had been a
> pain too as one was not able to modify the draft later one. It also
> removes the problems that can occure when mixing automimeproc:1,
> /^#/-lines, and your attachment system. In fact, instead of having two
> attachment systems, we only have one. It includes MIME forwarding too,
> which seems to be only too logical.
> 
> Of course there still are problems which need to be solved. The two
> mayor ones are:
> 
> (1) Less flexibility there are MIME structures that are not possible to
> create. We should carely evaluate which ones are really needed and how
> to access the full flexibiliy of mhbuild with the proposed system.
> 
> (2) MIME type guessing is very dumb. I'd like to see a system here
> that works out-o

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 23:21] Ken Hornstein 
>
> And if your
> email provider goes to an IMAP solution, you'll get to a point where
> nmh simply won't work for you anymore unless you're really hardcore
> and willing to cook up a bunch of crazy solutions ... and those
> people are becoming rarer and rarer.

(This quote only as a general starting point. If you take IMAP as
working in the remote mail storage with IMAP commands, then nmh's
basic mail storage concept would likely need to be abandonned. But
that's a different topic.)

Although you don't like to hear it, moving from being a complete mail
system that tries to handle everything about email to an only MUA
would solve many future problems.


Let me tell a story:

MH had been a large and common company with good, active employees
(developers) and good business (relevance). It covered everything
people needed to do emailing; emailing had been quite easy then.

Later, as the work of the employees decreased and email became more
difficult to handle (both may be connected) MH's business got worse
but still had been good enough. Then nmh came and took over the work
with partly new and motivated employees. They worked hard on covering
all this new email stuff. This had been an improvement for the
business.

Now we're back at the same poiint. The employees are less and work
less while emailing became even more complex. The business is quite
low currently, actually most people don't choose nmh anymore, although
it tries to provide everything for emailing, they just cannot use it
for ``normal'' (= modern) emailing. That's really sad. Unfortunately,
sad gets us nowhere.

In business the situation is clear: A heavy change needs to take place
in order to save the company from dying. Free Software is a bit
different but many of the general principles are similar.

What companies would do: Strip all the parts of the firm that are not
the core business. Then concentrate on the core/niche and try to gain
relevance there again. If this goes well, the company can grow its
product portfolio again.


Emailing is so complex and nmh has only few active development. We
simply cannot keep up. We cannot still provide a whole emailing
system; we have problems in each part. Nmh falls back behind more and
more and the effort that we are able to do is too small because of the
large code base that we want to maintain with few development power.


Of course nmh can go along like it did, but how vivid will it be in
some years? Of course there exists a lot of projects with ancient code
in order to provide compatibility, but that's almost dead code. Next
generations will have read of it in their history books ... great!

I would understand if you some of you want to have nmh stay as it is
because that's all they need and all the kind of emailing they do and
will do for the rest of their life. But for the others, I really do
believe that we need to figure out how to go for the future. And that
might include general changes, maybe a fork. (I'm really thinking
about forking myself and developing an experimental version as a show
case.)


I am young and I have my life in front of me and I am enthusiastic to
develop Free Software and I do want to use nmh still in many years and
I do want to be able to tell friends to use nmh without adding that
the really need to be able to suffer hard if they want to try.


meillo


P.S.
I had been in emotion writing this. I do not want to put up all this
discussion that keeps you from developing. Though, it seems to me as
if we need to think about the future some day do. It will not happen
tomorrow or next week, but somewhen we're in the future, suddenly.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 21:39] Jon Steinhart 
> 
> Sorry if I sound like an asshole here, but a while
> back the sending of attachments bugged me so I fixed it (without breaking
> anything).

I do believe that do did a very good work with your attachment system,
in fact it had been the inspiration and basis for my work.


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Joel Uckelman]

Thus spake Lyndon Nerenberg:
> 
> I would be surprised (stunned, really) if anyone was still using MH 
> *exclusively* as their MUA. 

Right here. Be surprised.

-- 
J.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal) [really mime parsing]

[Jon Steinhart]

Wow.  Woke everyone up it seems.  Good morning!

>   | A big thing that someone could do to help me with this would be to
>   | collect all of the various grammar into a single document.
> 
> Aside from intellectual curiosity, no, I don't think that's either
> needed or useful.   We know we can never have everything, as there's
> sure to be something new appearing tomorrow - the right solution is
> to deal with  the general principles properly, not to attempt to be
> able to handle every detail (even less so, as half the world's mail
> systems generate improperly formed messages, if we think we know what is
> correct, half - or more - the mail we ever see will fail).

This isn't intellectual curiosity.  It would help *me*, and *I'm* volunteering
to do a bunch of the work.  If you would like to do the work without this then
more power to you.

> nothing done with Yacc will last until the water gets hot -
> it looks too closely to tolerate nasty, external reality.

I've done a lot of lex and yacc and I don't agree.  But again, if you're
stepping up to do the work you can do it your way.

I'll try to restate my point from my last message.  This discussion isn't moving
things forward.  I'd like to move forward and would prefer that it not be a solo
effort.  Are any of you willing to help?  If so, let's get started and have a
dialog about how to proceed.  I'm a lot more flexible on the mechanics if I'm 
not
going it alone.  Let's use our energy to make progress.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 07:43] Jon Steinhart 
> 
> Sorry, seems like my comments offended you.  nmh is a community project.  To 
> me
> that means that anybody can propose things but those things are subject to 
> review
> by the larger community.  The result usually turns out to be better.  This 
> doesn't
> mean that your efforts aren't appreciated.  It helps to have a thick skin; 
> it's
> easy to get offended when people you've never met make comments.

Thanks. Yes, the thick skin is something I often lack.


> Maybe I don't understand your proposed changes.  Apologies if I get this 
> wrong;
> I didn't save a copy of your original email and the archives are currently 
> down.
> 
> There are currently -attach options on send and whatnow to support the 
> non-standard
> attachment header.  I don't even think about this because my .mh_profile 
> includes:
> 
>   send: -alias aliases -attach X-MH-Attachment
>   whatnow: -attach X-MH-Attachment
> 
> My understanding is that your change would be to remove the -attach options 
> and to
> have the .mh_profile include something like this instead:
> 
>   attach: X-MH_Attachment

That's only the minor change I made (in order to enable any program to
take part without the need to add the -attach switch to all of them).
I did it because it reduces overall complexity and simplifies the
configuration (which currently is very complex; you can hardly use nmh
without spending weeks in setting everything up once).

This change, AFAIS, only breaks with the versions since you added your
attachment system and only in the way that the -attach switch is not
recognized. One hardly wants to define some non-standard attachment
header anyways, therefore my version adds a default one. The
attachment format needs to be specified differently if one likes to
change it.

Where compatibility does get broken is that my attachment system would
always be active, while your's by default would not. But that's the
crucial point!

As I said above, currently nmh can hardly be used (for modern emailing,
that people probably like to do) with the default setup. Everyone of
us, of course has his rather complex setup which does what he likes,
so you don't see this problem anymore. I needed about two month until
nmh had been well configured. This included Jerry Peek's book or
course, the man pages and the pretty old FAQ. I needed lots of time to
figure out all the stuff. You often don't know if it is broken or if
you just haven't found out where you need to configure what.

Hence I would like to see nmh do the most likely thing per default.
This for instance includes converting foreign charsets to the native
one on show. This also includes the definition of the attachment
header. I asked myself why a user or system administrator should need
to set it manually. I fould no answer besides some corner cases where
the behavior would change.

If no such header is present and all text is ASCII then the behavior
is the original.

If a header is present or non-ASCII is used then the message is
MIMEified. This very likely is what is intended.  For sending
non-ASCII text without MIME I don't know. My patch MIMEifies in any
case if it's non-ASCII.

Therefore my patch removes the need to run `mime' at the whatnow
prompt. Why does the user need to decide if he needs MIME or not?
Mostly he does not know an will MIMEify always. Then plain ASCII
messages are MIMEified too which is not necessary. My patch does the
more reasonable thing.

Further more it does not require the user to know about mhbuild(1)
directives and makes /^#/ non-special (that's what your system
provided). Running mime at the whatnow prompt to early had been a
pain too as one was not able to modify the draft later one. It also
removes the problems that can occure when mixing automimeproc:1,
/^#/-lines, and your attachment system. In fact, instead of having two
attachment systems, we only have one. It includes MIME forwarding too,
which seems to be only too logical.

Of course there still are problems which need to be solved. The two
mayor ones are:

(1) Less flexibility there are MIME structures that are not possible to
create. We should carely evaluate which ones are really needed and how
to access the full flexibiliy of mhbuild with the proposed system.

(2) MIME type guessing is very dumb. I'd like to see a system here
that works out-of-the-box, in order to avoid heavy configuration on
setup. Adding douzends of mhshow-suffix- lines in the profile appears
merely as a workaround. GNU file(1) provides -i which provides the
information needed, but this is not portable (actually SUSv3 requires
-i to mean something else).


> Here are my unfiltered thoughts on this; maybe seeing them you can craft a 
> more
> compelling rationale for your proposed change:
> 
>  1.  It doesn't fix anything because the current mechanism isn't broken.

It's not broken but it is still clumpsy from the user's perspective.

>  2.  It doesn't simplify anything from a user 

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Joel Uckelman]

Thus spake Robert Elz:
> Date:Wed, 01 Dec 2010 21:39:37 -0800
> From:Jon Steinhart 
> Message-ID:  <201012020539.ob25db6v024...@darkstar.fourwinds.com>
> 
>   | A big thing that someone could do to help me with this would be to
>   | collect all of the various grammar into a single document.
> 
> Aside from intellectual curiosity, no, I don't think that's either
> needed or useful.   We know we can never have everything, as there's
> sure to be something new appearing tomorrow - the right solution is
> to deal with  the general principles properly, not to attempt to be
> able to handle every detail (even less so, as half the world's mail
> systems generate improperly formed messages, if we think we know what is
> correct, half - or more - the mail we ever see will fail).
> 
> We need to understand the general principles of header fields, and MIME
> separators, etc, and then understand exactly those elements that are
> required for the job that is needed - and simply ignore everything else
> (leave that for someone who needs it, and can understand and add that
> code, or simply ignore it totally if it adds no value for us).

It's probably not necessary to fully implement RFC822 parsing (e.g.,
does anybody use bang paths these days?) but trying to proceed on
"general principles" when you have a well-defined spec in hand is folly.

-- 
J.

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 14:02] David Levine 
> meillo wrote:
> 
> > The point is, we collide at any point. It's the community on the one
> > side and me on the other. At least this is how it feels to me. I
> > realize that my opinions and point of view is quite different from
> > your's (at least of those who speak up).
> 
> I trust that all opinions expressed on the issues have been
> based on good reason and intent.  Please don't feel that any
> sides are being taken, especially against an individual.
> Suggestions for improvements are always welcome by me, and
> by others from what I've observed here.

Thanks.


> > It seems to me as if you would be doing compatibility for
> > compatibility's sake. This is sticking to old cruft. Caring to much
> > for some old userbase likely keep you from getting new users while old
> > ones slowly vanish. This also includes frontends. It is a dead end.
> 
> If it's old cruft that works, I'm happy to stick to it.  If
> anyone wants to fix things under the hood, without breaking
> anything, or add new capabilities, great!

Hmm that's then the basic point where we differ. I do care if the
inside is clean and I rather like to remove features than add ones.
>From my point of view these are key factors to maintainability and
thus for the future of the code. One of the most important properties
of software is the question if the concepts are most simple and
implemented best possible. If at some time the concepts are found to
be imperfect, I really favor for change.

I do not like esr much, but he really hits the point in the chapter
``Popclient becomes Fetchmail'' in ``The Cathedral and the Bazaar''.
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html

But I understand that compatibility keeps us from there, and that's
the real point where I hit against. I dislike that by maintaining
compatibiliy we result in a worse solution as wo could achieve when
losing compatibility.

> At this point, compatibility has got to be part of nmh's goal.
> It was even at its inception, according to docs/README.about:
>   "intended to be a (mostly) compatible drop-in replacement for MH"

I admit that providing a drop-in replacement is a fully valid goal. I
rather dislike the fact that this looking back holds us from going
forward. (It's more a general problem, though.)


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 18:48] "Lyndon Nerenberg (VE6BBM/VE7TFX)" 
> 
> And MH, by its very intent, is a highly flexible tool.  When you understand
> the value of its tool-based approach to handling mail, you'll realize that
> most of the functionality you want you can add yourself by writing shell
> scripts around the existing commands; there no need to add everyone's
> pet functionality into the core.

But you cannot switch to, in this modern email world, more appropriate
concepts this way. I'm thinking about MIME handling in general. Yes,
MIME support had been added back then, but nmh's concepts did not
change in respect to MIME. Probably a lot of stuff had been done
right, but some may not.

> Which isn't to say things don't need to be changed.  But the die-hard MH
> user community has been using this software for over two decades, and most
> of us are unimpressed by the Linux way of doing 'software development.'

Do you think that the then taken conceptual decisions will be correct
forever? One thing I learned from, what you call the Linux way of
doing 'software development' is that later you'll always know better
and hence you should change. Nothing remains the same.

Note that I do not declare that I know better than you how to do
everything, but I think about change and how better concepts could
look like.


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

[2010-12-01 23:21] Ken Hornstein 
> 
> Like it or not, MIME messages are a reality in email today.  For
> example, when my boss sends me email from her Blackberry, it comes
> as a text/plain but encoded in base64, which nmh doesn't handle
> very well.  What exactly am I supposed to do here; tell the person
> who decides whether or not I get a raise, "Hey, your email client
> sucks, get a better one"?  Especially when every OTHER email client
> handles this just fine?  I doubt she has any idea what base64 is and
> quite honestly there's no reason for her to know about it.
> 
> >MH was written by and for people who have a deep understanding of how email
> >works, and who want to exploit the capabilities of email to the n-th degree.
> >These people also tend to be pretty hard core about the fundamentals of
> >software engineering, one of which is avoiding change for changes sake.
> 
> I agree that was true maybe 20-30 years ago, but I am wondering:
> What does Marshall Rose or John Romine use as an email client today?
> Maybe they still use mh or nmh, but it sure wouldn't surprise me
> if they don't (if we've lost Jerry Peek, then the game really IS
> over).  Hell, I met Brent Welch, the author of exmh, a few months
> ago at a conference; he told me that while he still wants to support
> exmh, most of the time his email client is PC-based.


> But we
> do need to think about the email we receive today and how we deal
> with it.  My mom sends me email today that nmh doesn't handle well;
> I don't know what my daughter's email is going to look like, but I
> can pretty much guarantee that she's not going to limit herself to
> 7-bit ASCII :-/  And while I like the nmh gang here just fine, if
> I can't use it to communicate with my mom or my daughter, then what
> the hell is nmh really good for?

Well said.


> I don't know yet if I agree with Markus's proposed changes (I will
> confess that I haven't read it completely; that's not due to a lack
> of interest, but a lack of time),

I suppose that more of you haven't thought enough about it. This
means mainly the topic and the proposed way (which is actually Jon's
attachment system) to approach it. My implementation might be bad but
I really believe that the approach itself is good.

One advantage that I have by being quite new to nmh: I still can look
at nmh from the outside.


> but at least he's starting
> a conversation that needs to take place.  For that I am grateful.

Thanks. :-)


meillo

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Mike O'Dell]

as usual, Robert is the voice of rational pragmatism.

nothing done with Yacc will last until the water gets hot -
it looks too closely to tolerate nasty, external reality.

however, i do note the following paper holds out the tantalizing
prospect of efficient *and* (relatively) comprehensible descriptions of
highly, if not rigorously, strutured text objects.

http://arxiv.org/abs/1010.5023

as for MH, i still use MH as my mail repository and *tolerate*
the UW-IMAP server's attempt to use it as well. I do this because
while i read a lot of mail using Thunderbird, no "sealed" mail
UA has the kind of flexibility to find things when you grossly
misfiled them (for instance).  in the spirit of "lively discussion",
what about

Do an MH-like plug-in for Tbird/Mozilla/etc ?

all the machinery that's nasty corner cases is there inside Tbird -
what MH provides is a way to orchestrate it in ways other than
the pre-ordained "work flows" built into the code. that might end
up being *more* useful given the somewhat awkward machinations
required to build complex shell-based code with MH.

this would extend the useful life of the MH world-view and expose
it to a lot more people without them having to join
The First Church of the Sanctified Shell Script.

think of it as "schoolyard samples" if nothing else.

-mo


On 12/2/10 3:22 AM, Robert Elz wrote:

 Date:Wed, 01 Dec 2010 21:39:37 -0800
 From:Jon Steinhart
 Message-ID:<201012020539.ob25db6v024...@darkstar.fourwinds.com>

   | A big thing that someone could do to help me with this would be to
   | collect all of the various grammar into a single document.

Aside from intellectual curiosity, no, I don't think that's either
needed or useful.   We know we can never have everything, as there's
sure to be something new appearing tomorrow - the right solution is
to deal with  the general principles properly, not to attempt to be
able to handle every detail (even less so, as half the world's mail
systems generate improperly formed messages, if we think we know what is
correct, half - or more - the mail we ever see will fail).

We need to understand the general principles of header fields, and MIME
separators, etc, and then understand exactly those elements that are
required for the job that is needed - and simply ignore everything else
(leave that for someone who needs it, and can understand and add that
code, or simply ignore it totally if it adds no value for us).

Fortunately the e-mail stuff has evolved in a way that is still highly
compatible even with rfc733, and those that preceded it (let alone 822
and the more recent editions) which allows us to presume that that trend
will continue, and if we take a moderately liberal parsing approach
to deal with what a field looks like, and a very conservative approach
to generation, producing only what should be understood by everyone,
we should get success.

kre

ps: depending upon whether "nmh only" includes exmh or not, I'm also an
nmh only user, I it (with exmh for better mime support...) for all of
my e-mail, and nothing else at all (again, assuming you're willing to
extend nmh to include the rest of the command like tools, like grep, and vi,
and ...)


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Robert Elz]

Date:Wed, 01 Dec 2010 21:39:37 -0800
From:Jon Steinhart 
Message-ID:  <201012020539.ob25db6v024...@darkstar.fourwinds.com>

  | A big thing that someone could do to help me with this would be to
  | collect all of the various grammar into a single document.

Aside from intellectual curiosity, no, I don't think that's either
needed or useful.   We know we can never have everything, as there's
sure to be something new appearing tomorrow - the right solution is
to deal with  the general principles properly, not to attempt to be
able to handle every detail (even less so, as half the world's mail
systems generate improperly formed messages, if we think we know what is
correct, half - or more - the mail we ever see will fail).

We need to understand the general principles of header fields, and MIME
separators, etc, and then understand exactly those elements that are
required for the job that is needed - and simply ignore everything else
(leave that for someone who needs it, and can understand and add that
code, or simply ignore it totally if it adds no value for us).

Fortunately the e-mail stuff has evolved in a way that is still highly
compatible even with rfc733, and those that preceded it (let alone 822
and the more recent editions) which allows us to presume that that trend
will continue, and if we take a moderately liberal parsing approach
to deal with what a field looks like, and a very conservative approach
to generation, producing only what should be understood by everyone,
we should get success.

kre

ps: depending upon whether "nmh only" includes exmh or not, I'm also an
nmh only user, I it (with exmh for better mime support...) for all of
my e-mail, and nothing else at all (again, assuming you're willing to
extend nmh to include the rest of the command like tools, like grep, and vi,
and ...)


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Valdis . Kletnieks]

On Wed, 01 Dec 2010 21:39:37 PST, Jon Steinhart said:

> One of the big pieces that's needed is a modern mail parser.  As per earlier
> emails, I think that this is complex enough that it's a job for lex and yacc.
> 
> A big thing that someone could do to help me with this would be to collect all
> of the various grammar into a single document.  I'm willing to write the code
> for it, but I'm not a complete rfc junkie and find the whole thing hard to
> read.  If some of you could slog through the rfcs and collect this stuff we
> could make some real progress.

There's several ways to go here.  The actual grammar is (mostly) in RFC5322,
except for the MIME headers (which are mostly simple enough that a simple
ad-crock parser should be able to deal with it, just "Fieldname: [tag=value]*"
for the most part.  Parsing the tag/value pairs is easy - the semantics are a
pain because they're often context-sensitive (ignore this tag unless this other
tag doesn't say 'inline', etc...).

Large chunks of the grammar are there only for crufty corner cases (if anybody
is interested, read section 3.1.4 of RFC822 for an example of its awesomeness)

Just because I remembered seeing it before, here's a rfc822 address
validator, done as one Perl regexp:

http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

Yes, you really want to use lex/yacc to build a parser instead. :)

And then the question of what to do when certain other common MUAs and MTAs
manage to ignore the RFCs and produce something ugly - although the biggest
offender is still the various poorly written spamware out there.  But since no
spam filter is 100% effective, we *do* have to be robust in the face of crap.

Unfortunately, parsers created from a BNF or similar tend to be a tad
brittle when recovering from syntactically incorrect input (anybody ever
had a missing ) or } leave an error message 500+ lines away from the
actual error?



pgp5thVn91qZI.pgp
Description: PGP signature
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Jon Steinhart]

Hey, hate to be a party pooper but I don't see how this whole discussion
is helpful.

I use nmh.  It needs to be brought up to date in a few places.  For me,
that's the MIME stuff.  Sorry if I sound like an asshole here, but a while
back the sending of attachments bugged me so I fixed it (without breaking
anything).  Reading MIME messages still needs work, I've been talking about
how I think it should be fixed for a while.  I'm working on it now when I
have spare time.

It would be cool if y'all could put some energy into this effort.  You clearly
have the energy to wax poetic about nmh.  Put that energy into improving it.

One of the big pieces that's needed is a modern mail parser.  As per earlier
emails, I think that this is complex enough that it's a job for lex and yacc.

A big thing that someone could do to help me with this would be to collect all
of the various grammar into a single document.  I'm willing to write the code
for it, but I'm not a complete rfc junkie and find the whole thing hard to
read.  If some of you could slog through the rfcs and collect this stuff we
could make some real progress.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[belg4mit]

>I would be surprised (stunned, really) if anyone was still using MH 
>*exclusively* as their MUA.  I haven't done so for years.  Today I have 
MH/nmh is the only MUA I've used for personal mail over the past 14 years,
barring the *rare* forwarding to gmail to process certain attachments,
and if it handled MIME a bit better (and I could find the tuits to get
AFS working) I wouldn't do that ;-)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Paul Fox]

lyndon wrote:
 > I would be surprised (stunned, really) if anyone was still using MH 
 > *exclusively* as their MUA.  

i do.

=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 38.1 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Paul Fox]

ve6bbm/ve7tfx wrote:
 > > i think it's less a popularity contest than a desire to have someone
 > > interested enough to manage the website and packaging when the rest of
 > > us are all out in our rocking chairs on the porch, tapping our canes, and
 > > muttering about the good old command-line days...  :-)
 > 
 > But that's not at all what's being proposed.
 > 
 > Or maybe my Alzheimer's is creeping up and I missed it.  But I don't
 > think so.

you're right.  but the point of new users (and of future maintainers,
as alluded to above) is part and parcel with the question of relevancy
that ken raised.  if mh can't do what people want (need) from an email
client, then there will soon be little reason at all to use it, and
even less to maintain it.  i can get away with using mh for work
because i'm fairly picky about my chosen jobs, and i'm willing to
tolerate a lot of pain to stay on the commandline.  my wife gave up on
mh for work some time ago -- she still uses it for her home mail, but
i can see the writing's on the wall.

i'd like to see new mh users because i'd love to see a larger
potential population of interested maintainers, which would increase
mh's relevancy, which would help guarantee that i'll still be able to
use it from my rocker on the porch.  (and, btw, i'm willing to give up
some (well-documented) backwards compatibility to do that.)

paul
=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 40.8 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Lyndon Nerenberg]

On 10-12-01 8:21 PM, Ken Hornstein wrote:

I agree that was true maybe 20-30 years ago, but I am wondering:
What does Marshall Rose or John Romine use as an email client today?
Maybe they still use mh or nmh, but it sure wouldn't surprise me
if they don't (if we've lost Jerry Peek, then the game really IS
over).  Hell, I met Brent Welch, the author of exmh, a few months
ago at a conference; he told me that while he still wants to support
exmh, most of the time his email client is PC-based.  And if your
email provider goes to an IMAP solution, you'll get to a point where
nmh simply won't work for you anymore unless you're really hardcore
and willing to cook up a bunch of crazy solutions ... and those
people are becoming rarer and rarer.


I would be surprised (stunned, really) if anyone was still using MH 
*exclusively* as their MUA.  I haven't done so for years.  Today I have 
a regular rotation of about six MUAs I use on a near-daily basis, and I 
usually have three of them running concurrently.  There's no one MUA in 
existence that can (or could) handle all the varying types of media that 
get thrown around now.  And even of the ones that do handle, say, ical 
objects, which of the three I choose to use for a particular message 
depends on its context (work v. personal v. hobby stuff).  In that 
spectrum, MH is just one of the tools I use to plow through the deluge 
of mail I receive every day.  I use it for the tasks it's good at, and I 
don't pretend it's the solution for dealing with highly complex 
interactive media messages, for which there are more suitable tools.


Now I agree completely that MH really needs to do a better job with 
MIME.  But the solution is not to turn it into a python-based rewrite of 
Evolution.


--lyndon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Ken Hornstein]

>> It seems to me as if you would be doing compatibility for
>> compatibility's sake. This is sticking to old cruft. Caring to much
>> for some old userbase likely keep you from getting new users while old
>> ones slowly vanish.
>
>Why do we need new users?  When did this become a popularity contest?

Sigh.  It's not a popularity contest; it's a RELEVANCY contest.  As
in, nmh is becoming less and less relevant in it's basic function:
communicating with other people via email.

As part of the conversion to git, I had a chance to troll through the
nmh mail archives looking for old email addresses, and something stark
came across to me: we're losing users.

These aren't casual users; for example, Kimmo Suominen, someone who did
a LOT of nmh coding back in the day, announced that he finally gave up
on nmh here (in 2005!):

http://www.mail-archive.com/nmh-workers@nongnu.org/msg00429.html

Like it or not, MIME messages are a reality in email today.  For
example, when my boss sends me email from her Blackberry, it comes
as a text/plain but encoded in base64, which nmh doesn't handle
very well.  What exactly am I supposed to do here; tell the person
who decides whether or not I get a raise, "Hey, your email client
sucks, get a better one"?  Especially when every OTHER email client
handles this just fine?  I doubt she has any idea what base64 is and
quite honestly there's no reason for her to know about it.

>MH was written by and for people who have a deep understanding of how email
>works, and who want to exploit the capabilities of email to the n-th degree.
>These people also tend to be pretty hard core about the fundamentals of
>software engineering, one of which is avoiding change for changes sake.

I agree that was true maybe 20-30 years ago, but I am wondering:
What does Marshall Rose or John Romine use as an email client today?
Maybe they still use mh or nmh, but it sure wouldn't surprise me
if they don't (if we've lost Jerry Peek, then the game really IS
over).  Hell, I met Brent Welch, the author of exmh, a few months
ago at a conference; he told me that while he still wants to support
exmh, most of the time his email client is PC-based.  And if your
email provider goes to an IMAP solution, you'll get to a point where
nmh simply won't work for you anymore unless you're really hardcore
and willing to cook up a bunch of crazy solutions ... and those
people are becoming rarer and rarer.

>And MH, by its very intent, is a highly flexible tool.  When you understand
>the value of its tool-based approach to handling mail, you'll realize that
>most of the functionality you want you can add yourself by writing shell
>scripts around the existing commands; there no need to add everyone's
>pet functionality into the core.

I don't think anyone is suggesting the basic idea of the tool-based
approach that is the core of the MH concept be abandoned.  But we
do need to think about the email we receive today and how we deal
with it.  My mom sends me email today that nmh doesn't handle well;
I don't know what my daughter's email is going to look like, but I
can pretty much guarantee that she's not going to limit herself to
7-bit ASCII :-/  And while I like the nmh gang here just fine, if
I can't use it to communicate with my mom or my daughter, then what
the hell is nmh really good for?

I don't know yet if I agree with Markus's proposed changes (I will
confess that I haven't read it completely; that's not due to a lack
of interest, but a lack of time), but at least he's starting
a conversation that needs to take place.  For that I am grateful.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> i think it's less a popularity contest than a desire to have someone
> interested enough to manage the website and packaging when the rest of
> us are all out in our rocking chairs on the porch, tapping our canes, and
> muttering about the good old command-line days...  :-)

But that's not at all what's being proposed.

Or maybe my Alzheimer's is creeping up and I missed it.  But I don't
think so.


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> make that 3 decades

I got into the game late.  We didn't get our own 9 track drive until
1986.

It wasn't until I moved to the coast (2004) that I finally tossed out
that MH source tape.

--lyndon


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Paul Fox]

ve6bbm/ve7tfx wrote:
 > > It seems to me as if you would be doing compatibility for
 > > compatibility's sake. This is sticking to old cruft. Caring to much
 > > for some old userbase likely keep you from getting new users while old
 > > ones slowly vanish.
 > 
 > Why do we need new users?  When did this become a popularity contest?

i think it's less a popularity contest than a desire to have someone
interested enough to manage the website and packaging when the rest of
us are all out in our rocking chairs on the porch, tapping our canes, and
muttering about the good old command-line days...  :-)

paul
=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 46.8 degrees)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Mike O'Dell]

make that 3 decades

On 12/1/10 9:48 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:

It seems to me as if you would be doing compatibility for
compatibility's sake. This is sticking to old cruft. Caring to much
for some old userbase likely keep you from getting new users while old
ones slowly vanish.


Why do we need new users?  When did this become a popularity contest?

MH was written by and for people who have a deep understanding of how email
works, and who want to exploit the capabilities of email to the n-th degree.
These people also tend to be pretty hard core about the fundamentals of
software engineering, one of which is avoiding change for changes sake.

And MH, by its very intent, is a highly flexible tool.  When you understand
the value of its tool-based approach to handling mail, you'll realize that
most of the functionality you want you can add yourself by writing shell
scripts around the existing commands; there no need to add everyone's
pet functionality into the core.

Which isn't to say things don't need to be changed.  But the die-hard MH
user community has been using this software for over two decades, and most
of us are unimpressed by the Linux way of doing 'software development.'

--lyndon


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> It seems to me as if you would be doing compatibility for
> compatibility's sake. This is sticking to old cruft. Caring to much
> for some old userbase likely keep you from getting new users while old
> ones slowly vanish.

Why do we need new users?  When did this become a popularity contest?

MH was written by and for people who have a deep understanding of how email
works, and who want to exploit the capabilities of email to the n-th degree.
These people also tend to be pretty hard core about the fundamentals of
software engineering, one of which is avoiding change for changes sake.

And MH, by its very intent, is a highly flexible tool.  When you understand
the value of its tool-based approach to handling mail, you'll realize that
most of the functionality you want you can add yourself by writing shell
scripts around the existing commands; there no need to add everyone's
pet functionality into the core.

Which isn't to say things don't need to be changed.  But the die-hard MH
user community has been using this software for over two decades, and most
of us are unimpressed by the Linux way of doing 'software development.'

--lyndon


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[David Levine]

meillo wrote:

> our relationship is a bit special. I came in February and it
> resulted in a big discussion on MTAs and the like. I came again
> recently, had been active, proposed improvements, but feel like
> running agains walls.
> 
> The point is, we collide at any point. It's the community on the one
> side and me on the other. At least this is how it feels to me. I
> realize that my opinions and point of view is quite different from
> your's (at least of those who speak up).

I trust that all opinions expressed on the issues have been
based on good reason and intent.  Please don't feel that any
sides are being taken, especially against an individual.
Suggestions for improvements are always welcome by me, and
by others from what I've observed here.

> The main topic of our disagreement is compatibility.

As I'm sure you're aware, many of us have been using mh/nmh
for a very long time (decades!).  Whatever its deficiencies,
it works.  Furthermore, I use nmh a _lot_.  So compatibility
is quite critical.

> It seems to me as if you would be doing compatibility for
> compatibility's sake. This is sticking to old cruft. Caring to much
> for some old userbase likely keep you from getting new users while old
> ones slowly vanish. This also includes frontends. It is a dead end.

If it's old cruft that works, I'm happy to stick to it.  If
anyone wants to fix things under the hood, without breaking
anything, or add new capabilities, great!

> I value clearer and simpler solutions above compatibility in any case.
> I understand the importance for compatibility in case of a backend,
> but it should never be for it's own sake, but this is what I feel here
> again and again.
> 
> Is nmh just good enough for you and therefore better not changed? Is
> updating your setups once a year more effort than the improvements of
> modernization? It could be and I would understand. The point is:
> 
> What is the goal of nmh?

At this point, compatibility has got to be part of nmh's goal.
It was even at its inception, according to docs/README.about:
  "intended to be a (mostly) compatible drop-in replacement for MH"

> That's what I don't understand. No matter what I try to do, I conflict
> with you. This indicates that we probably have too different views of
> nmh.
> 
> 
> With pleasure I see the discussion of nmh2 which could finally be a
> step in my direction. But before I cheer too much up, I'd better know:
> 
> What's the goal for nmh2, if it should come to happen?

Good question.  I think it can allow more rapid evolution
of nmh because it wouldn't be as bound by compatibility and
portability:

1) It can be a fork of the current nmh code base.
2) It can be a proving ground for new ideas and implementations.
   If some are deemed suitable for inclusion into nmh, that's
   fine.  If not, that's fine, too.  It should be useful and
   usable on its own.
3) It can sacrifice compatibility, whereas nmh must try to
   avoid user-visible, incompatible changes.
4) It can be implemented in languages other than C.
5) It need not be portable to odd (say, non-POSIX) platforms.

I don't care what "it" is called.

> Having the goals clearly stated would allow me to figure out if it's
> worthwhile for me to try to add value to this community and project.
> If someone has personal opinions on this subject, I welcome them too.
> 
> Nmh is clearly your project and not mine, besides being Free Software.
> I don't want to sail in your waters if you don't like.

I don't think it's necessary or useful to think in such terms
as "your" and "mine".  And I, for one, welcome your (and anyone
else's) suggestions.

David

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Ken Hornstein]

>It seems to me as if you would be doing compatibility for
>compatibility's sake. This is sticking to old cruft. Caring to much
>for some old userbase likely keep you from getting new users while old
>ones slowly vanish. This also includes frontends. It is a dead end.

I symphathize with your viewpoint, but if we are voting, I'd try to
come down on the side of compatibility if possible.  Of course,
we can always argue about whether or not existing behavior is "right"
or even worth preserving; that's one of the things that has no right
or wrong answer, it's a constant balancing act that requires a judgement
call every time something new is proposed, and of course different
people have different judgement.

>Is nmh just good enough for you and therefore better not changed? Is
>updating your setups once a year more effort than the improvements of
>modernization? It could be and I would understand. The point is:

Well, for me nmh isn't quite good enough right now; I wish it would do
some things better.  And I'm not the only one:

http://kb.mit.edu/confluence/x/iwFt

The main reasons listed there?  Lack of IMAP support and poor MIME
handling.  Okay, on the first point there are diverging opinions, and
I can at least respect other viewpoints on how nmh should deal with
IMAP (or even if it should).  But right now when it comes to MIME
we kinda fail for a lot of common use cases.  I don't view this as being
due to a lot of difference of opinions on what we should do; I think
the real issue is that dealing with MIME is hard, given the age of the
codebase and the basic question of what you should do with things like
UTF-8 messages on a plain tty.

>What is the goal of nmh?
>
>That's what I don't understand. No matter what I try to do, I conflict
>with you. This indicates that we probably have too different views of
>nmh.

I guess my personal view is that nmh is a set of simple, modular Unix
tools for dealing with email, and the goal of nmh is to deal with those
messages (read, file, delete, reply) from the Unix command line
interface.  Note that when I say "simple", I mean the user interface to
those tools is as simple as possible; the tools themselves can be
complicated.

>With pleasure I see the discussion of nmh2 which could finally be a
>step in my direction. But before I cheer too much up, I'd better know:
>
>What's the goal for nmh2, if it should come to happen?

I think others will have to speak to that; I'm okay with nmh continuing
without having an nmh2.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Jon Steinhart]

> Hoi nmh community,
> 
> our relationship is a bit special. I came in February and it resulted
> in a big discussion on MTAs and the like. I came again recently, had
> been active, proposed improvements, but feel like running agains
> walls.
> 
> The point is, we collide at any point. It's the community on the one
> side and me on the other. At least this is how it feels to me. I
> realize that my opinions and point of view is quite different from
> your's (at least of those who speak up).
> 
> The main topic of our disagreement is compatibility. I like to point
> this out here, quoting replies to my proposal:
> 
> Subject: Re: [Nmh-workers] [patch] snapshot of my MIME handling improvments
> [2010-11-12 17:55] Jon Steinhart 
> > 
> > I have difficulty seeing this as enough of a savings to be worth breaking
> > backward compatibility.  If you really have to do this then you should
> > provide an upgrade script so that users don't get their stuff broken when
> > they upgrade.
> 
> (On the former sentence, see below. On the latter sentence, I agree.)
> 
> Subject: Re: [Nmh-workers] MIME questions, and followup to my earlier email
> [2010-11-12 19:50] Jon Steinhart 
> > 
> > On my earlier email, I guess that I'm unhappy that meillo is making changes
> > that break things, even if those are minor things.  Comments on my proposed
> > MIME-reading changes indicated that they should be optional for 
> > compatibility
> > reasons.  I took that approach when I implemented the MIME-sending changes.
> > I think that we should only break existing code for clear and compelling
> > technical reasons.
> 
> It seems to me as if you would be doing compatibility for
> compatibility's sake. This is sticking to old cruft. Caring to much
> for some old userbase likely keep you from getting new users while old
> ones slowly vanish. This also includes frontends. It is a dead end.
> 
> I value clearer and simpler solutions above compatibility in any case.
> I understand the importance for compatibility in case of a backend,
> but it should never be for it's own sake, but this is what I feel here
> again and again.
> 
> Is nmh just good enough for you and therefore better not changed? Is
> updating your setups once a year more effort than the improvements of
> modernization? It could be and I would understand. The point is:
> 
> What is the goal of nmh?
> 
> That's what I don't understand. No matter what I try to do, I conflict
> with you. This indicates that we probably have too different views of
> nmh.

Sorry, seems like my comments offended you.  nmh is a community project.  To me
that means that anybody can propose things but those things are subject to 
review
by the larger community.  The result usually turns out to be better.  This 
doesn't
mean that your efforts aren't appreciated.  It helps to have a thick skin; it's
easy to get offended when people you've never met make comments.

Maybe I don't understand your proposed changes.  Apologies if I get this wrong;
I didn't save a copy of your original email and the archives are currently down.

There are currently -attach options on send and whatnow to support the 
non-standard
attachment header.  I don't even think about this because my .mh_profile 
includes:

send: -alias aliases -attach X-MH-Attachment
whatnow: -attach X-MH-Attachment

My understanding is that your change would be to remove the -attach options and 
to
have the .mh_profile include something like this instead:

attach: X-MH_Attachment

Here are my unfiltered thoughts on this; maybe seeing them you can craft a more
compelling rationale for your proposed change:

 1.  It doesn't fix anything because the current mechanism isn't broken.

 2.  It doesn't simplify anything from a user perspective.

 3.  It just looks like a "semantic sugar" sort of change.

 4.  It breaks things for existing users.

 5.  Does he know that options can go into the .mh_profile?

 6.  I don't see any pros to outweigh the con of breaking things.

I would suggest that if there is a compelling reason for your change that you 
could
do it without removing the old code.  That way your new mechanism would work 
without
breaking anything.

I know people who have crafted their own custom environments around the current
mechanism and an upgrade script is unlikely to catch them.  nmh has a small but
dedicated user community and breaking things upsets them.

Finally, I think that the goal is to keep improving nmh which to me means 
cleaning up
the codebase, fixing bugs, and adding new features.  Your proposed change 
doesn't appear
to do any of these unless I'm missing something.

Jon

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: [Nmh-workers] Understanding nmh (aka. What's the goal)

[Peter Maydell]

markus schnalke wrote:
>It seems to me as if you would be doing compatibility for
>compatibility's sake. This is sticking to old cruft. Caring to much
>for some old userbase likely keep you from getting new users while old
>ones slowly vanish. This also includes frontends. It is a dead end.
>
>I value clearer and simpler solutions above compatibility in any case.
>I understand the importance for compatibility in case of a backend,
>but it should never be for it's own sake, but this is what I feel here
>again and again.
>
>Is nmh just good enough for you and therefore better not changed? Is
>updating your setups once a year more effort than the improvements of
>modernization? It could be and I would understand.

I think compatibility is critical for any "mature" software project.
Breaking it should always be a really big deal, only done if there
is absolutely no way around it, and announced clearly in upgrades.
(Even then it's hard to be sure users will notice -- consider the
case of individual users on a multiuser system who get a new nmh
version as a result of the sysadmin doing a distribution upgrade.
The sysadmin might see release notes (but likely not), the users
certainly won't.)

This isn't particularly nmh specific. Any time you break back compat
it annoys all your existing users.

Basically, if your project is still new, under development and in
some sort of 0.xx version you can get away with breaking compatibility
in pursuit of code cleanup. As the project ages the tradeoffs change.

I do want to see nmh improved, but if compatibility is broken
this needs to be for a really good reason, and the "new" setup
must be fully thought out so it doesn't have to change again,
and well documented and changes loudly advertised in changelog
and release notes.

I don't see any reason why we can't make nmh better than it is:
the principle barrier has IMHO been that there haven't been enough
people who have had the time/effort/inclination to actually write
the code to improve things. (I also think that this is a more
sensible approach than the "throw away and rewrite" idea and
I'd prefer it if we didn't use "nmh2" as a name for the latter.)

-- PMM

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

[Nmh-workers] Understanding nmh (aka. What's the goal)

[markus schnalke]

Hoi nmh community,

our relationship is a bit special. I came in February and it resulted
in a big discussion on MTAs and the like. I came again recently, had
been active, proposed improvements, but feel like running agains
walls.

The point is, we collide at any point. It's the community on the one
side and me on the other. At least this is how it feels to me. I
realize that my opinions and point of view is quite different from
your's (at least of those who speak up).

The main topic of our disagreement is compatibility. I like to point
this out here, quoting replies to my proposal:

Subject: Re: [Nmh-workers] [patch] snapshot of my MIME handling improvments
[2010-11-12 17:55] Jon Steinhart 
> 
> I have difficulty seeing this as enough of a savings to be worth breaking
> backward compatibility.  If you really have to do this then you should
> provide an upgrade script so that users don't get their stuff broken when
> they upgrade.

(On the former sentence, see below. On the latter sentence, I agree.)

Subject: Re: [Nmh-workers] MIME questions, and followup to my earlier email
[2010-11-12 19:50] Jon Steinhart 
> 
> On my earlier email, I guess that I'm unhappy that meillo is making changes
> that break things, even if those are minor things.  Comments on my proposed
> MIME-reading changes indicated that they should be optional for compatibility
> reasons.  I took that approach when I implemented the MIME-sending changes.
> I think that we should only break existing code for clear and compelling
> technical reasons.

It seems to me as if you would be doing compatibility for
compatibility's sake. This is sticking to old cruft. Caring to much
for some old userbase likely keep you from getting new users while old
ones slowly vanish. This also includes frontends. It is a dead end.

I value clearer and simpler solutions above compatibility in any case.
I understand the importance for compatibility in case of a backend,
but it should never be for it's own sake, but this is what I feel here
again and again.

Is nmh just good enough for you and therefore better not changed? Is
updating your setups once a year more effort than the improvements of
modernization? It could be and I would understand. The point is:

What is the goal of nmh?

That's what I don't understand. No matter what I try to do, I conflict
with you. This indicates that we probably have too different views of
nmh.


With pleasure I see the discussion of nmh2 which could finally be a
step in my direction. But before I cheer too much up, I'd better know:

What's the goal for nmh2, if it should come to happen?

Having the goals clearly stated would allow me to figure out if it's
worthwhile for me to try to add value to this community and project.
If someone has personal opinions on this subject, I welcome them too.

Nmh is clearly your project and not mine, besides being Free Software.
I don't want to sail in your waters if you don't like.


meillo


P.S.
In any way do I appreciate the new activity on the project. :-)

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers