On Sun, 29 Aug 2021 at 14:17:10 +0900, Charles Plessy wrote:
> Judging from IANA's registered types for other script languages, it
> looks like the application type is more relevant. Also, the
> application/ types appear first in our /etc/media.types file, and if I
> remember well this gives them precedence anyway. A quick random check
> in the Internet shows that there is no consistency on how shell scripts
> are served, but that the application type is used among others.
The major difference is fallback behaviour. If a client (web browser or
email client or similar) receives a file with a text/* type for which it
has no special handler, in the absence of other context it is expected
to treat it like text/plain, and show the file to the user as text. If a
client receives a file with an unknown application/* type, it is expected
to treat it like application/octet-stream, assume that viewing the file as
text would be pointless because the user wouldn't necessarily understand
it anyway, and offer to save it or open it in an external program instead.
Using types outside text/ is definitely appropriate for very verbose text
languages like SVG and "flat" OpenDocument, where it's *technically*
text, and *technically* you could edit it with a text editor, but in
practice that's rarely what anyone wants.
For scripting languages like sh and Python, I'm not sure: either way
could be appropriate. Which is more common: sharing scripts as source
code to read and edit, or sharing scripts as executables to download
and run as-is? If the former, text/ makes sense, if the latter,
application/.
If scripts and other source code are to be served as application/*, it
would be good to check that all our "programmer's editor"-style programs
have a MIME association set up for that type. In an extremely quick survey
of the .desktop files of editors I happen to have installed on my GNOME
laptop: gedit (a text editor) only registers itself to handle text/plain,
GNOME Builder (an IDE for programmers) handles both text/ and application/
for a wide variety of languages, and gvim (a text editor in hard mode :-)
mostly only handles text/ types, except for application/x-shellscript
where it only has application/ and not text/ for whatever reason.
smcv
