Repository navigation
App/Plugin API for mimetypes #9192
Description
Activity
Yes, that seems to get more important as we get more and more apps that can handle different filetypes.
Associating custom callbacks to handle mimetype opening
OCA.Files.fileActions.register should already work fine for that I think, we would actually need to have some mechanism to define the default action there as described in nextcloud/viewer#2393
While reworking the mimetype registry it could also be considered to not base it (solely) on file extensions but also check magic headers and provide APIs to register them based on those. Likewise the API should consider multiple filetypes and headers to map to a single mimetype and probably allow to set up all these mappings in a single call.
See #7098 for that as well.
@juliushaertl : @jhass set that as a pre-requisite to solve jhass/nextcloud-keeweb#67
Is there any safe workaround for users while this is being developed ?Up to today a lot of issues (#7098, #10131, #2081, #15, ...) have been raised on nextcloud github which do need a proper mimetype handling like jhass proposed it. It would greatly enhance the useability of some apps (e.g. OwnPad, Audioplayer, Keeweb, ...) so that an administrator does not need to modify any files by hand anymore.
If we also want to add a graphical user interface (only for admins?) some sort of what they have in firefox would be useful:?
Would such a graphical user interface make sense?Has things evolved on this topic?
Is it under development for nextcloud 17 or 18 for example?I apparently asked my question at the wrong place, sorry... The list for nextcloud 17 might not to be done any more but already decided. Hopefully for 18
I had a look around, and the DICOM viewer expands the mimetypes by extending the Migration. Is this a way forward?
I had a look around, and the DICOM viewer expands the mimetypes by extending the Migration. Is this a way forward?
Yes. Their migration is a very smart way to do that. It adds the mimetype definition to the database and create a custom mappings file for the user (that's actually a setup user should do manually but working with json is error prone so that's clever). I used a different way for the keeweb app but I like the DICOM approach more.
Shouldn't one way or the other be propagated in some kind of docs then?
I think it would be good to have a recommended way how to handle mimetypes in one of the next releases.Any update on this issue?
With new files to vue (28), all actions are still shwon in the menu, so you'll be able to select different options for a same mimetype
You will also be able to find the new API here: https://nextcloud-libraries.github.io/nextcloud-files/classes/FileAction.html
(some parts are still in the server repo and will be pushed to@nextcloud/filessoonReacted by Daniel and Pierre Ozoux
Metadata
Metadata
Assignees
Type
Projects
- Status
Hey,
as an application/plugin developer I want an API to fully, properly and easily manage mimetypes. That is
Creating a new mimetype
I think this should be enough if it's on install, but a general API wouldn't hurt. Adding a new mimetype would trigger a background rescan of the database to associate any files with the new type.
Removing a mimetype
Probably also enough on uninstall. Perhaps apps could just declare these in their manifest. Again this would update the file database accordingly.
Associating custom callbacks to handle mimetype opening
This sort of exists with
OCA.Files.fileActions.register, but was completely undocumented last time I checked. It probably also could use some cleanup and convenience APIs for common cases.Making this easy probably also requires nextcloud/viewer#2393 as we then would likely get competing apps for the same mimetypes.
While reworking the mimetype registry it could also be considered to not base it (solely) on file extensions but also check magic headers and provide APIs to register them based on those. Likewise the API should consider multiple filetypes and headers to map to a single mimetype and probably allow to set up all these mappings in a single call.