Using non-standard mimes

[gmcgibbon]

Seeing how with mime-types you can do MIME::Types.add(some_new_type) to add non-standard mimes, does this gem have any plans on supporting this feature in some way?

[jeremy]

No plans, as the lib is designed for use with static db files fronted by a small memory cache. Could investigate supporting this though, e.g. by allowing you to

• specify your own static db files to replace those bundled with the gem, or
• provide your own db object which checks for custom types then delegates to the builtin Db

Retaining perf and resource consumptioin characteristics for mainline usage is important though.

[gmcgibbon]

Right, I was thinking of providing an API to point to custom db files to check when the primary db doesn't have a definition. That way only custom cases should be affected. I'll see if I can prototype something and PR it.

[SamSaffron]

sure, but I really don't want to suffer any perf hit here for the extra flexibility here. Maybe have a place you call upfront to point it at a different set of DB files, then you would override the location of the DBs after you require the gem.

Also, super curious for an actual example here of the problem mime type, is the root issue that the mime type gem is slow to accept new mime types?

[gmcgibbon]

Maybe have a place you call upfront to point it at a different set of DB files, then you would override the location of the DBs after you require the gem.

Sure, I haven't started yet so I can go for that approach instead if we think it's better.

is the root issue that the mime type gem is slow to accept new mime types?

No, its mainly because I'm not comfortable upstreaming the MIME changes in our app because I think some of them are wrong. We treat *.sass and *.scss as text/css and support *.liquid, which doesn't have an official content type. I considered upstreaming the liquid MIME but there's a debate as to what the content type should actually be.