Idea: revamp file associations and MimeMap

…something that’s been annoying me for a while on RISC OS is the general approach to filetype handling, and I’m thinking there’s room for improvement, so I thought I’d throw up a thread here.

My understanding is that the current way everything is handled regarding filetypes boils down to this:

Individual applications can register a filetype with Set File$Type_XXX, and associate that filetype with themselves using the Set Alias$@LoadType_XXX, Set Alias$@RunType_XXX, and Set Alias$@PrintType_XXX commands. This mechanism is prone to applications stealing associations upon being looked at, requiring careful use of the “Look at” mechanism in !Configure’s Boot settings to make sure the right application has a file association.

Internet and foreign filesystems use MimeMap to translate MIME types, RISC OS filetypes, and foreign filesystem file extensions between one another. MimeMap is a text file that is hand-edited, with no way for an application to register new MIME types other than asking the user to copy chunks of MimeMap files into their own local copy of MimeMap (or maybe using a merge utility), a potentially error-prone process.

My proposal: Create a filetype database that replaces the File$Type and LoadType/RunType/PrintType mechanisms, as well as the MimeMap.

As this would replace File$Type, I’m thinking there would be a call that an application could provide a hex type, a friendly RISC OS name, and optionally a preferred MIME type and any alternate MIME types, and any file extensions. This would be backwards of the current use of MimeMap, where MIME types come first – that may have performance implications for anything using the current MimeMap module? (I think compatibility implications would only arise if a MIME type ends up associated with multiple RISC OS filetypes, but presumably this could be checked for and errored on.) If a filetype already has been registered with the system, and the friendly name is the same, any MIME types/file extensions specified by the caller could merely be added to the list. If it is not the same, an error could be returned to the caller.

(Additionally, anything using the current File$Type system could presumably be translated to a registration into this system, it just wouldn’t get MIME types or file extensions.)

Regarding LoadType/RunType/PrintType, I’m thinking setting them as aliases could “merely” be handled differently (although new commands underlying those specific behaviors may be a good idea for reasons I’ll explain below) – instead, any application that sets those aliases instead gets stored in the database as a handler for those actions. If no handler currently exists, then an application becomes default upon registering – the same behavior as today. If a handler already exists, however, the new application does not become default. And, as there would be a database stored in the !Boot structure, this would all persist across reboots. (A toggle could possibly be added to change this behavior, too, to behave closer to the current state.)

Then, a !Configure applet could be created to manage filetypes graphically, showing the hex type, the friendly name, the first MIME type, the first file extension, and the current application specified by LoadType/RunType/PrintType. Opening a filetype would allow seeing and changing all of the MIME types, all of the file extensions, and all of the currently registered LoadType/RunType/PrintType settings for that filetype.

Applications would also not be able to destroy associations through the existing mechanisms, only add to them – the existing mechanisms being deprecated.. (I’m looking directly at you, !ZapUser. Also note that I have Opinions™ on what !Boot scripts are able to do now, that are off-topic for this discussion.) Presumably new commands – and style guide additions to tell applications not to do this without explicit user consent – would be available to do this, though, because I don’t like the idea of locking it only behind !Configure.

(Also, I think this ends up touching OLEServer stuff too? And also TaskWindow stuff, for completeness – obviously TaskWindow isn’t a filetype, but it has filetype-like attributes and I’d like to see it managed through this UI.)

Is there anything I’m missing for why this would be a bad idea, or not feasible, or not liked?

Also this should include VRPC that currently uses a different machanism of its own, causing grief when trying to keep them synchronised.

My proposal: Create a filetype database that replaces the File$Type and LoadType/RunType/PrintType mechanisms, as well as the MimeMap.

Not a good idea. It would break too much.

any MIME types/file extensions specified by the caller could merely be added to the list.

Being able to add MIME types dynamically would be a good idea.

Not a good idea. It would break too much.

Note that I was proposing leaving the old commands for accessing those behaviors (just silently allowing them to add to this database), although I suspect that would be ugly to actually implement due to hacks to the command interpreter to special-case this.

(Of course, I’d be way in over my head actually trying to implement this.)

I think you are proposing a new command which an application could use to create both a RISC OS application/fileype association enivornment variable and add a fileype/extension MIMEMAP entry. It would work where there is a one to one relationship, but in other cases there may be many applications which can handle a certain filetype, but there should only be one MIME map entry. I’m thinking of the video players which can handle all different formats of video, but don’t agree on what extension they should have.