[480] in Release_7.7_team
Re: mh and mime
daemon@ATHENA.MIT.EDU (Mike Barker)
Fri Apr 12 12:48:31 1996
To: John Hawkinson <jhawk@MIT.EDU>
Cc: release-team@MIT.EDU, sol24@MIT.EDU, irix53@MIT.EDU
In-Reply-To: Your message of "Thu, 11 Apr 1996 17:39:42 EDT."
<199604112139.RAA03970@lola-granola.MIT.EDU>
Date: Fri, 12 Apr 1996 12:48:24 EDT
From: Mike Barker <mbarker@MIT.EDU>
I've added the two porting lists to maintain continuity in those
discuss archives.
:) . 2. We should disable mime operation by default. E.g.,
:) . setenv NOMHNPROC 0
:) . seems to put mh back into a "non-mime" state. This can be probably be
:) . done in a global fashion.
:)
:) Hmm; it would seem to make more sense to change the binary to
:) not use mime stuff by default and then have the environment variable
:) turn it on....
I'd like to respond on two levels.
First, as a basic principle for our group, I think we have to deal
with packages that are obtained from somewhere else as "hands-off"
code. I.e., we should NOT make changes unless required. When we do
make changes, we should try to use the provided customization
facilities first.
It doesn't matter whether we have source or not, with limited
resources we must consider most packages as "third party" software and
NOT make changes.
This principle ensures that we do not accidentally add support and
maintenance of our local hacks in the indefinite future to a list of
tasks for limited resources.
Second, at the level of the code, mh is NOT a single binary. it is
more like a swarm of cooperating programs. I did a quick check and
found that at least three uip (User Interface Programs, I think--it's
been a while since I delved into mh) code segments specifically refer
to the environment variable. mshcmds, show, and whatnowsbr would all
have to be modified to reverse the sense of the default and change the
convention for the environment variable.
Even worse, since mh can be used as the underlying "mail system",
changing the external interface as you suggest could mean that we
would have mysterious failures of packages that use the conventional
mh interface. We would then be forced to change those programs also.
I'm not sure what sense, aside from aesthetic, you are referring to,
but making a gratuitious change in the conventions provided by a
widely used package seems rather nonsensical to me.
:)
:) . 3. We should document and publicize that mime support is provided.
:) . This should include instructions for enabling it along with warnings
:) . about the default mhn handling (e.g., by default mhn will try to print
:) . postscript segments.)
:)
:) I meant to say this before, but have been a bit busy.
:)
:) CWIS is already maintaining a mailcap file that launches various
:) applications. Clearly there are some things that show up more
:) frequently on the web than in email, and vice versa, but there's a lot
:) of overlap. Someone needs to address the issue of whether the release
:) should have a global mailcap for all applications, and who maintains
:) that.
:)
:) It seems apparent (to me, at least) that a default that prints certain
:) types of things is inherently broken and needs to be modified before
:) the software is put in the release, mime on by default or not.
:)
The programmer on loan to cwis may want to comment on the notion that
CWIS is actively maintaining a mailcap file.
Incidentally, I know you haven't had time to check the mh
documentation or sources, but mhn does not appear to use mailcap. It
uses mhn_defaults. Same idea, perhaps similar formats. I may have
used the wrong file name in earlier messages, and I apologize for
confusing the issue.
I think that the idea of having "someone" analyze, lay out
alternatives, and propose a grand solution is a great idea. The
project will need to look at the various mailcap, mhn_defaults,
mime-types, and whatever other ways people are providing for handling
this. netscape, mhn, metamail, pine, and other mime variants in use
or likely to be used here all need to be included.
However, in the eight weeks (plus or minus two) that remain before the
release of solaris 2.4, it isn't going to happen. I'm adding it to
the list of urop ideas, and perhaps we will have a chance to revisit
it as a general issue in the fall.
I agree that the provided mhn_defaults are not very good. Since we
are checking things for the release, it is good that we found out now.
As an interim suggestion, I think we should simply remove bad entries
in the mhn_defaults file (e.g. the postscript printing). This would
This would
avoid complications when we have time to develop a reasonable
mhn_defaults set.
Thanks
mike
Incidentally, I checked the infoagents mailcap and mime-types files.
I also did some other digging. For information:
infoagents mailcap
---------------------------------
### this file was automatically generated using generate.m4 $Revision: 1.1 $
### Do not modify it manually, modify the template file (or the list of
### symbols defined on command line) instead.
#
# template for mailcap for Netscape
#
# $Source: /mit/infoagents/lib/Netscape/RCS/mailcap.template,v $
# $Id: mailcap.template,v 1.6 1996/02/28 20:36:42 brlewis Exp brlewis $
#
video/mpeg; /mit/graphics/arch/@sys/bin/mpeg_play %s;
video/*; /mit/graphics/arch/@sys/bin/xanim %s;
# We should probably provide a better solution than this...
audio/*; /mit/infoagents/arch/share/bin/showaudio %s;
application/postscript; /mit/gnu/bin/ghostview %s;
application/x-dvi; xdvi %s;
# we have acroread for this platform in infoagents.
application/pdf; /mit/infoagents/arch/@sys/bin/acroread %s;
---------------------------------
infoagents mime-types
---------------------------------
application/pdf pdf
video/fli gl
video/fli fli flc
video/iff iff
video/pfx pfx
video/avi avi
video/rle rle
video/smc smc
video/rzpa rzpa
type=x-world/x-vrml exts=wrl,vrml
---------------------------------
list of commonly occurring types (from mhn man page)
---------------------------------
Type Subtypes
---- --------
text plain, richtext
multipart mixed, alternative, digest, parallel
message rfc822, partial, external-body
application octet-stream, oda, postscript
image jpeg, gif, x-pbm, x-pgm, x-ppm, x-xwd
audio basic
video mpeg
---------------------------------
/usr/athena/etc/mhn_defaults
---------------------------------
mhn-charset-iso-8859-1: xterm -fn '-*-*-medium-r-normal-*-*-120-*-*-c-*-iso8859-*' -e %s
mhn-show-application/PostScript: %plp -dps
mhn-show-image/gif: %pgiftoppm | ppmtopgm | pgmtopbm | pbmtoxwd | /usr/athena/bin/xwud -geometry =-0+0
mhn-show-image/x-pbm: %ppbmtoxwd | /usr/athena/bin/xwud -geometry =-0+0
mhn-show-image/x-pgm: %ppgmtopbm | pbmtoxwd | /usr/athena/bin/xwud -geometry =-0+0
mhn-show-image/x-ppm: %pppmtopgm | pgmtopbm | pbmtoxwd | /usr/athena/bin/xwud -geometry =-0+0
mhn-show-image/x-xwd: %p/usr/athena/bin/xwud -geometry =-0+0
mhn-store-application/PostScript: %m%P.ps
mhn-store-text: %m%P.txt
---------------------------------
