utopia depends on mime-types >= 0

[halostatue]

I'm preparing mime-types 2.0 for release, and it has some breaking API changes (not for most uses, but some esoteric features). The most important API change is that mime-types 2.0 no longer supports Ruby 1.8.

If this matters, the gemspec needs to be changed from >= 1.16 to ~> 1.16.

[ioquatix]

Nice, thanks for the note. Just wondering, why not have a separate file for the new features and only require it if they are supported by the language version?

e.g

if RUBY_VERSION >= "2.0.0"
    require "mime-types/feature-2.0.0"
else
    require "mime-types/feature-1.8"
end

[halostatue]

Because I've rather changed the internal structure of how everything gets loaded (I depend on the presence of the json library as defined in Ruby 1.9.2, and json_pure does not work with my JSON files in my tests) and I'm not planning on maintaining two versions of that—and I've started using constructs like:

add(*types, :silent)

You can see the full set of changes at mime-types/ruby-mime-types#41 if you're interested. Long term, I want to try to make it so that I can update the data files independently of the library (e.g., people start depending on mime-types the data files, which brings in mime-types-core the code), but the two are tightly tied together at this point—and may be (mostly) inseparable.

[ioquatix]

I see.

Here is something which could be useful. I started writing code to deal with mime-types in Utopia, which can serve files via HTTP and thus requires the mime type. The code is here:

http://github.com/ioquatix/utopia/blob/master/lib/utopia/middleware/static.rb

Basically, I need to quickly look up a file extension and find the mime type. The user can specify symbolic names which are then resolved using your library to an actual mime type.

It would be quite nice if something like this was supported by mime-types library. For example, given a list of file extensions, return the list of mime types.

In addition, there are lots of mime types which are not supported by your library, I don't know if that's because they aren't standard or just unusual, e.g. ogg/vorbis, etc.

By default, I added this layer to handle those cases. Perhaps that can be better solved by your library somehow.

[halostatue]

Wouldn't at least part of that be:

>>> MIME::Types.of('html')
=> [text/html]

Granted, this is for one file at a time, but I think it wouldn't be hard to add array parsing to MIME::Types#of so that it can handle a list of types. Maybe I'll add that for 2.0 (see mime-types/ruby-mime-types#42) as I have to give people time to protect themselves if they need to still support Ruby 1.8 (which I can understand, but I haven't used Ruby 1.8 in two years).

Also, regarding a lot of the types—many of those have been added. All I need is a bug report and I'll add it; better, if I get a pull-request, I can add that very quickly.

>> MIME::Types.of('ogg')
=> [audio/ogg, video/ogg]
>> MIME::Types.of('ogx')
=> [application/ogg]

[ioquatix]

That is excellent that most of those types have been added.

In addition to resolving extensions, I also do symbolic expansion, e.g. :fonts, :archives, etc. Could be useful to define categories of mime types relating to general functional purpose.

[halostatue]

Can you add a feature request for symbolic/category expansion? I have a bit of code that I've changed for 2.0 that I might just look at rewriting for the concept of categories. When you do, if you could identify your categories, that would help me substantially—I need to make sure that the data is updated as well as the code for category support.

[ioquatix]

This functionality has been revamped.

https://github.com/ioquatix/utopia/blob/14bf541b168f95600d276584625bb1080798c503/lib/utopia/static.rb#L32-L114

It might make sense to merge in something similar to MimeTypeLoader into the mime-types gem.