mime-types should not forcibly require json

[postmodern]

mime/type.rb requires 'json' but the mime-types gem does not dependent on any json gem. mime/types.rb seems to only require json for the to_json method. This could be moved into a separate file, or maybe only define #to_json if defined?(JSON). mime/types/loader.rb uses JSON to load data/mime-types.json, but perhaps this could be converted to YAML to avoid the json dependency?

[halostatue]

It is correct that the mime-types gem does not depend on any JSON gem because json.rb is part of the Ruby standard library in Ruby 1.9 and later (see #55). I also did some benchmarking of JSON against YAML against my hand-rolled Regex parser (from v1) as I was preparing to move to v2, and the JSON version was consistently faster than the YAML version (and both stomped all over my hand-rolled parser, which I was dropping anyway because it didn’t provide enough information).

The json included with the Ruby standard library works, but json-pure does not. So…I’m not going to change the default format (and it’s going to be a bit more important moving forward to 3.0 because of the competing imperatives I have with #67 and #83).

What I can probably do is remove the require 'json' from mime/type.rb (meaning that MIME::Type#to_json is defined anyway, but will blow up if you do not have a JSON library loaded), and make it only used in mime/types/loader.rb if JSON is not otherwise loaded.

[postmodern]

@halostatue ah ha, I believe it's because bundler is excluding json for some reason.

There's another option which would be the much efficient, but not as elegant. Instead of generating a JSON document, generate a Ruby file that defines a giant literal Array of content types.

[halostatue]

That’s certainly a possibility, and worth considering for 3.0—it may help with the memory use and provide somewhat smarter/lighter data loading (I’d love to be able to get lazy loading really granular, because it would do more to help #83 than anything else).

I’m still going to be generating the JSON in some form of 3.0 because I’ve ported the core functionality to Io and want to do the same for a few other languages (as a learning exercise), plus someone ported mime-types (v1) to Python a few years ago, and they recently got a issue requesting a bump to the v2 data, so I think that the software-readable data that I’m providing is of value, and JSON is a fairly clean (and mostly safe) way to do that in a way that YAML implementations are less likely to provide.

[halostatue]

I will certainly benchmark the startup time of an array vs. the JSON. I suspect that it will be faster than JSON, and if that’s the case, it’s worth pursuing all on its own.

[halostatue]

The default registry store for mime-types 3.0 is the columnar store, required with require 'mime/types' or with require 'mime/types/columnar'. The JSON store will be used if you require 'mime/types/full' or do an explicit MIME::Types::Loader.new.load(columnar: false).

I’m not pursuing the idea of a generated array because of previously noted memory usage issues.