Re: [Nmh-workers] iCalendar support

[Robert Elz]

    Date:        Wed, 12 Nov 2014 21:03:25 -0500
    From:        David Levine <address@hidden>
    Message-ID:  <address@hidden>

  | If we want to handle MIME better, there will have to be changes
  | to nmh.

Of course, I was writing about iCalendar support only - I think that
"good enough" support for building MIME messages is (or sounds) very
close, and that's as far as we should really aim (leave the mhbild stuff
there for anyone who wants to use it, but I suspect that few do).
Anyone who needs more complex forms (mltipart/parallel anyone?) can
generate the message themselves... (if there re MH primitives to help,
fine, otherwise it can be done the hard way, and fed directly to the MTA)

For dealing with repl, which is what is the biggest concern to most of us,
I think, the real question seems to be what that means.   Obviously a
few things are fairly clear, but the general reqirements are a mystery to
me - I have no idea what I wold like it to do - that makes designing a
solution hard.

  | Rather than reinventing the wheel every time, we should use
  | what's already in nmh.  It already has base64 and q-p decoders
  | (and two base64 encoders!).

That's all fine, and yes, I agree, certainly reuse whatever exists.
I just did not want to presume that they were there already.
[I haven't looked inside nmh for a very long time.]


  | That's the point, almost.  Experience to date has been that
  | contrib doesn't work well.

I certainly have no problem adding it as a mainstream command, if
that is agreed to be useful - contrib just allows stuff to be tested
a bit first, and perhaps for there to be a few different approaches being
trialed before (perhaps) one of them is moved into the main codebase.

I also understand Ken's point about te difficulty of teaching old dogs
new tricks - and generally teaching new users about everything that is
available.   I also understand that some users expect everything to
"just work" out of the box, but I'm not sure that that kind of user
will really get much benefit from nmh - for may people, hotmail or
gmail (or whatever) really are what they need.   There's nothing wrong
with that.   Similarly, with most current MIME viewing, using a GUI
type interface makes things much easier - and rather that attempting to
figure out how to make everything perfect from the command line interface
it might be better to spend more time commnicating with the exmh and
sylpheed developers (and perhaps others, if there are any that can deal
with MH format messages) and with procmail for mail reception, and get
all of that better integrated.

address@hidden said:
  | So I think that leads me to think that the default tools should give you
  | some indication that text/calendar support is available.

I disagree - that's entirely the wrong direction, show doesn't print
some message about "Now do you want to reply, forwrd, ..." every time
it displays a message, scan doesn't tell the user how to display the
messages, ...

No question that better doc is needed (Jerry's book is getting kind of
dated) but that's where people need t be shown what's available, and
how to use it.

Treating ical as a special case will just lead to demands for similar
treatment of the next magic mime type that becomes popular.  Please
don't go there.

kre