[haiku-development] MimeType aliases.
- From: Bruno Albuquerque <bga@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 26 Nov 2008 09:26:38 -0200
Sometime ago we started discussing the possibility of implementing
MimeType aliases but no conclusion was reached. I decided to revisit it
while looking at some Tracker stuff and came up with a proposal that I
think may work for the majority of cases and with a trivial
implementation in the sense that would mostly use the current
implementation with some small additions here and there.
First, some background.
I discovered that older versions of SoundPlay (v4.7.3 and below, more
specifically) work almost flawlessly(*) under Haiku so I started it on
all my Haiku installations.
As SoundPlay is a bit old, it looks for the MPEG audio file mimetype as
audio/x-mpeg (which was before it was made a standard type) while
Haiku's default MPEG audio file type is audio/mpeg (the newer official
type). This results in 2 different entries in the MIME database that
represents exactly the same type and make searching for MP3 files by
type a bit confusing.
What would the method described below fix?
- It would allow aliases for MIME types (audio/x-mpeg would be nothing
but an alias to audio/mpeg) to work seamlessly.
- Identifying untyped files would always give them the main type (i.e.
the one that is not an alias).
- Force identifying types would also give them the main type.
- Changes to a main type (adding/removing attributes or changing sniffer
rules) would automatically apply to all aliases.
- Probably some other subtle stuff I didn't think about yet.
What would it *NOT* fix?
- It does not help in the case that what we want basically amounts to
multiple types associated with a file. For example, we could have a text
editor application that would generate files with some XML-like
formating and that associates the application/myapplication MIME type to
documents created by it. Cnsidering the document is plain text we may
want to also associate this file with text/plain or text/xml.
- Something else?
Design:
- Backend.
The backend for the new design would be the same MIME database we
already have. The difference is that besides having the MIME types there
as we have today, we would also have standard symbolic links. In the
audio/mpeg and audio/x-mpeg example, we would have something like this
on disk:
audio
mpeg
x-mpeg -> mpeg
Where "x-mpeg -> mpeg" represents a symbolic link named x-mpeg that
points to the mpeg file in the same dir.
This is the entire change in the backend. Nothing else would have to be
done (I told it was trivial).
- BMimeType API.
When BMimeType internally opens a type file, it will do that by
resolving the link (if it is a link) and opening the target file
instead. This will make any changes made to the alias MIME type to be
done in the main MIME type. Also sniffer rules and other stuff would be
read from the main MIME type as expected.
In the example I mentioned, SoundPlay would check for the audio/x-mpeg
file and would successfully open it (so it would not create it) but what
it would actually get is the audio/mpeg type.
- Registrar/Identify.
This is part of the code I did not look into yet (experts, please fill
me in) but basically what happens is that when iterating through all the
types to identify a file (is this how it works?) it would have to ignore
any alias types.
- preferences/FileTypes
This would have to list all types but either show the aliases in a
different color (or in italics or in any other way to differentiate them).
When a main type is selected, show the usual interface but with the
addition of control where you can mark it as an alias and point to a
specific main type.
When an alias type is selected, it also shows the standard interface
plus the control to mark it as alias. This would of course already be
marked and pointing to the main type associated with it. All information
listed will be the one for the main type.
If you have a main type and switches it to be an alias, the backend
would replace the actual file in the backend database by the wanted link
and reload the data to show the new status.
If you have an alias type and switches it to be a main type, the backend
would copy the pointed to main type and replace the link by this copy
and reload the data to show the new status.
- Find panel.
As with these changes all the files in the system would converge to only
the main MIME types we have 3 options in the Find panel:
1 - Do not change anything. The drawback is that when searching by type
some files may not show up (audio/x-mpeg files would not show up on a
search for audio/mpeg). Note that in this case the find panel would show
all types, main and aliases and would only search for the mime type
string selected. I think this is the worse option (althougn the easiest).
2 - Show only main types in the type selection and count on the fact
that eventually all files will converge to only main types. This has the
drawback that if a file has not switched from audio/x-mpeg to audio/mpeg
yet it won't be found in a query by the main type.
3 - Show only main types but do the query by adding all the alias types
to the query formula. This would guarantee that all identified files
(even the one with alias types) would be picked up but would also make
the query a bit slower.
Conclusion.
So I am probably missing something as this ones my first go at trying to
solve this problem. All opinions/comments are welcome.
-Bruno
Other related posts:
