Re: [PATCH] TM usability enhancements
Hrvoje Niksic <hniksic(a)srce.hr> wrote:
Darryl Okahata <darrylo(a)sr.hp.com> writes:
> However, your idea of dynamically determining the type based upon
> file contents in an excellent suggestion (and would also solve the
> current .diff/.patch dichotomy).
I think it is the wrong thing to do. Encoding should be based upon
the file contents in the sense of the presence of 8bit chars, etc.
Type should be based on the semantics of the file.
I need to clarify this. This may (or may not) be different from
Ben's thinking, but I was NOT thinking about replacing the existing TM
code that determines the MIME type, etc. with something "fully
automatic". I'd agree that this would be the wrong thing to do, as (1)
it would be a LOT of work, and (2) we'd end up with basically a modified
version of /etc/magic. The pain and suffering would not justify the
questionable rewards.
I'm thinking about *augmenting* the existing TM code (this will
probably have to wait until post-21.0, though). A problem with the
existing code is that it's assumed that a particular file extension
(e.g., ".wav") always refers to a particular file type (e.g.,
"audio/x-wav"). This is the problem I want to solve. For example, the
extension ".patch" often refers to a plain text file that contains a
patch, but, on PCs (Win95/WinNT), I've seen ".patch" files that are
binary. For certain, select, file extensions, it would be nice if the
MIME types could be dynamically determined. In the case of ".patch",
"text/plain/quoted-printable" would be the default, unless "binary"
characters (0x00 or 0xff -- can any other characters be used to detect
binary files, in the presence of 8-bit characters?) are present, in
which case "application/octet-stream/base64" would be the default).
-- Darryl Okahata
Internet: darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.