Forum OpenACS Development: Re: primary key in cr_mime_types
- audio/x-mpeg in the database. When OpenACS delivers these files, some of these might have e.g. the first, some other the second mime-type. A browser will most likely behave different on those, the user has no idea, why....
- a unique constraint in the DB + a mapping table for incoming files that maps different incoming mime-types to a canonical, or
- using ns_guesstype always for delivery, no matter what the stored mime_type is.
When an e.g. mp3 file is stored in the static area, the mime-type might be resolved via ns_guesstype, maybe coming up with a forth variant...
actually, while iana recommends for mp3 audio/mpeg, mac OS X returns "audio/mpg", what i have used in the statement above. the mess is actually a real word mess.
so, for delivery, a unique mapping would be good. This could be achieved e.g. via
The mess is not yet to big. we have multiple mime_types for .mp3, .cdf and .wav
4 | mp3
2 | cdf
2 | wav
i think they can be standardized:
- we have: audio/x-mpeg, audio/mp3, audio/mpg, audio/mpeg
- IANA: audio/mpeg, Apache: audio/mpeg, mac: file -i audio/mpg
- we have: audio/x-wav, audio/wav
- Apache: audio/x-wav, mac: file -i audio/x-wav
- we have: application/x-cdf, application/x-netcdf
- Apache: application/x-netcdf
The only problem seems to be mp3, where indeed multiple ideas exist, trend towards audio/mpeg. I would say that handling this case in the file upload form via a configured ns_guesstype should be the way to go...