On June 6, 2000 at 13:49, Uffe Henrik Engberg wrote:
> 1) It would be useful if MHonArc considered more than just the last
> filename extension. To reduce mail size people often compress files
> before attaching them. Using only the last extension, e.g. .gz of
> file.ps.gz, in the file name means that browser does not know how
> to handle them after they have been saved. If .ps.gz is used, the
> browser knows that it just have to uncompress the file and call a
> PostScript viewer.
You regex is not sufficient. What about a filename like,
"SomePrg2.01.tar". What does "01" mean? The better approach is to
recognize compress filename extensions like ".gz", ".Z", etc and
handle those cases specially.
> 2) 12 Aug 1999 Earl Hood announced that he had added support for
> decoding uuencoded data within text messages in mhtxtplain.pl of
> MHonArc v2.4.2. I would like MHonArc to be able to handle other
> kinds of embedded files. Preferably specified through resources.
The uuencoded addition was reluctant, but since it is still common
for newsgroups, I did it. Handling other non-standard file attachment
schemes is a slippery-slope that I think provides very little benefit.
You also may have to deal with cases where users do not want a
all or nothing, but selective detection. For example, I want to
recognize PostScript data, but no other. So the extraction code will
need a list of what it should detect instead of blindly checking for
all data types it is designed to check.
I prefer to take a contributed filter approach. If someone has a
filter to handle non-standard cases like embeded PostScript data in a
text/plain message, and the person believes it will be useful to others,
they can document it, and contribute it. I have an extras/ directory
in the distribution for any useful contributions.
> 3) It is possible to tell MHonArc if it should gzip files it creates.
> It would be nice if one could instruct MHonArc to uncompress
> attached compressed files. Some of our users are on platforms where
> they do not necessary have the tools to make the needed
> uncompression.
I have considered this in the past. One problem is performance.
Another is to know what the proper media-type of the uncompressed data is
since the content-type setting will be application/x-gzip. And since
mhonarc does not key off filenames by default, and it may not even
be present, what then.
I think some users use Apache, and Apache can be configured to
auto-decompress gzipped data.
Questions, which platforms do you refer to? I have had no problems
getting software to handle gzip data on the different platforms I have
worked on.
> 4) Many attached files are not "web friendly", i.e. they are in a
> format one cannot expect the user to be able to view directly.
> However, our MHonArc server can turn many formats into pdf. If one
> could specify some post processing/hook filter MHonArc should call
> after saving an attachment, these converters could be activated.
Another custom mimefilter. Note, the issue of format and users not
being able read it is something the sender should consider.
> Regarding 1) it is sufficient to replace the line:
>
> ($nameparm =~ /\.(\w+)$/)) { # filename has an extention
>
> in mhexternal.pl with the line:
>
> ($nameparm =~ /\.(\w+(\.\w+)*)$/)) { # filename has extension(s)
No. See comment above.
> Regarding 2) I have made a slight modification of mhtxtplain.pl (patch
> enclosed) which not only extracts embedded uuencoded files but also
> embedded PostScript and LaTeX files. The modification is activated via
> an "extract" option.
> As it is now, these patterns are hard wired, but ideally they should
> be specified through dedicated resource types (MIMEARGS are not
> suitable). MHonArc has the ability to hook in own custom message
> filters, but unfortunately one cannot hook in own custom resource
> types.
How is MIMEARGS not sufficient for your case?
Note, I have thought about custom resources, but the/my need has never
been strong enough to actually figure out how to implement it. Any
solution would require a pre-registration step defining the custom
resources to recognize. It's doable, but does it really need to be
done.
--ewh
