MimeMap

In general, when you ask for a new RISC OS file type registration you will not automatically prompt a revision to the standard HardDisc4 MimeMap file.

A good example of this was the file type for .xlsx (Microsoft ExcelX) – no RISC OS application was initially able to load and display such files but a MimeMap entry was needed if such files were to be sent as an e-mail attachment or downloaded under RISC OS. It would also be necessary if you wanted to use external filing systems such as LanMan98 without the system tacking on a ,xxx suffix.

Another example is an ‘Anquet Export Format’ (.aef) file for which I shall have to make up a pseudo IANA filetype for the &A6F RISC OS filetype.

Unfortunately the MimeMap module was invented after the PRMs had been published and so there is very little documentation and no documentation at all about the SWI to check for a particular entry. There is (so far) no SWI to add an entry to the user’s MimeMap file.

My web service provider uses a non-standard MimeMap definition for a zip file: ‘application/x-zip-compressed’ (the ‘x-’ bit means that it is a made up description rather than a standard one which is why there are so many different variants foir a .zip file) and so any zip file downloaded from my web site will have a ‘.zip’ suffix and an IANA ‘file tpye’ as given. Some Browsers are clever enough to work out common RISC OS file types (e.g. Webster) from the ‘.xxx’ suffix but other Browsers are even cleverer (such as Netsurf) and get it wrong.

It doesn’t help that one of the last entries in the MimeMap file matches any unknown IANA (or non-IANA) filetype with &FFD (Data).

If a file is downloaded under a non-RISC OS operating system, it will simply be saved as ‘filename.typ’ and therefore seen, from RISC OS, with the correct filetype as there will be non IANA filetype to consider. It was a long time before I realised that this simpler method would not work for e-mail attachments – for example a file ‘name.doc’ attached to an e-mail might be seen as a text file on some systems rather than as a Word file and thus be unintelligible.

I am working on a method to update a user’s MimeMap file to include a specific entry (pending this facility being added to the OS) that will work on both VRPC and non-emulated systems:

10 : P=OPENUP("Boot:Choices.Default.Internet.Files.MimeMap")
20 : IF P=0 THEN P=OPENUP("Boot:Resources.!Internet.Files.MimeMap")
30 : SYS "MimeMap_Translate","application/x-zip-compressed" TO roft%
40 : IF P<>0 THEN
50 : IF roft%=&FFD THEN
60 : PTR#P=EXT#P
70 : BPUT#P,"application/x-zip-compressed Zip A91"+CHR$13
80 : ENDIF
81 : CLOSE#P
82 : ENDIF
83 : OSCLI("ReadMimeMap")
84 : END

this will correct the user’s MimeMap file. It doesn’t work correctly yet as it appends a line after the ‘match all’ line and the syntax of the SWI call is currently unknown so I may not have got it exactly correct – MimeMap_Translate is not documented in the PRM nor on the ROOL web site.

MimeMap_Translate wants:
R0 = 2
R1 = MIME type
R2 = 0
R3 = Buffer for output

I can’t remember what this all means or where I found the docs, but that’s what I’m doing in HTTPLib and it works correctly.

MimeMap_Translate is not documented in the PRM nor on the ROOL web site.

It’s in the StrongHelp manuals at least. I appear to have updated the list of translate types in September 2018, but even winding back to the 1999 version there was an outline of the SWI then too – the InetSWIs manual is also on RISC OS Pi of course.

Many thanks. I’ll have a look.

My web service provider uses a non-standard MimeMap definition for a zip file: ‘application/x-zip-compressed’

Would it not be better to tell your provider that they’re wrong?

http://www.iana.org/assignments/media-types/media-types.xhtml

Would it not be better to tell your provider that they’re wrong?

I do plan to do that as well.

the syntax of the SWI call

That will not help – it is is the syntax of the MimeMap file which you would need, as that is read and interpreted by the MimeMap module so that it can provide the MimeMap_Translate SWI call. And the only doc I can find of the file format are the brief comments at the start of the RO5 file.

The MimeMap SWI, and the file format have been documented since at least 2006 – I’m pretty sure they were included in my MimeMap module’s distribution, ANT’s documentation and the documentation supplied by Acorn later as well.

There was certainly a library for merging the MimeMap files in Select, as I recall. It was hastily put together and didn’t handle some cases very well, but it certainly was there.

The example code given by the original poster is incorrect in its accessing the choices files. There are a number of problems with it…

• Path variables may not be written to, and if you update them you will almost certainly not update the correct file (see the 3rd point).
• If you wish to write to choices, you need to write to <Choices$Write>.
• If you’re updating a file you must read the original file through the path variable then write to Choices$Write, not just open the file for update. If you open the file for update then you will be updating the earlier file in the path list, and not the one described in the $Write location.

BUT… those comments notwithstanding, the actual location of the MimeMap file is held in `<Inet$MimeMappings>`, which is what you should update. For historic reasons this variable contains a path variable – `InetDBase:MimeMap` – (), and the comments from above must be taken with a pinch of salt () if you want to update it because of this history.

On Select, if multiple paths are used the $Write variant will be selected, so if you do the ‘open, read the file, close, open, write the file, close’ sequence, it’ll work just fine. On other systems, unless similar changes will happen, the path variable is not able to be updated reliably when given multiple elements.

Additionaly, as mentioned by others, `application/x-zip-compressed` is just wrong, so you probably shouldn’t be trying to update it automatically in the MimeMap file. The `x-` prefix has been deprecated since oh, 2010-ish? The x- prefix (and it’s ‘modern’ counterpart `x.`) are ‘reserved for experimental use’. So just do it by hand.

There is a standard registered mime type for zip files – application/zip – which has been around since the early 90s (probably in the original batch of registered types), so it might be time to update the software to catch up.

I did ask for some advice from ROOL

> Is there a recommended way to ‘merge’ a new definition into a user’s
> MimeMap file (like Boot Merge or System update)? I feel reluctant to
> do it without user consent.

and their reply (on Sat, 15 Oct 2016 00:54:45 +0100) was:

Well, the comments in the MimeMap file suggest that the first non
wildcarded line is given preference, so I suspect it’s simply a matter of
scanning the file for your MIME type, and if not found then appending your
definition to the end of the file. Should be achievable in a few lines of
single-tasking BASIC. A simple utility that did that and nothing else could
be made reusable by taking the MIME type, filetype and extensions from its
arguments, then we could consider bunging that somewhere in !Boot for
others to use.

I’m thinking along the lines that there needs to be a system mimemap file as now, but also a user mimemap file for the users own customised settings. That way the system mimemap can be replaced in its entirety by Boot Merge, and not affect the user settings which would have priority,

I’m thinking along the lines that there needs to be a system mimemap file as now, but also a user mimemap file for the users own customised settings. That way the system mimemap can be replaced in its entirety by Boot Merge, and not affect the user settings which would have priority.

That’s a really good idea.