You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we defined the 1.0 of the mime-db it has worked well, expect for one of the properties: compressible. This property cannot be derived from the upstream data and instead rules must live in this repo to populate the value. By itself, this is not too bad, but it adds additional complexity to the module as well as inflates the size of the database for something many may not even use.
I'm thinking that a 2.0 version should drop this property from the database format and all related rules from this module.
The compressible data and ruleset would live on still, under the npm module compressible. Instead of delegating to this module for compressible data, it would instead be the store of all the rules (and would not even need to depend on this module).
I'm opening this up for thoughts on this proposal, especially for those who are dependent on the database format. I'm not planning to make any changes for quite some time. Perhaps in a few months at the earliest, so there is plenty of time for feedback to fall here, if any.
The text was updated successfully, but these errors were encountered:
That being said I think we'll just end up having like compressible-db or something, because I'm pretty sure we'll just end up needing another giant JSON blob.
Maybe it's better to do more sniffing for text / text-related encodings in the data itself. I dunno.
Since we defined the 1.0 of the mime-db it has worked well, expect for one of the properties:
compressible
. This property cannot be derived from the upstream data and instead rules must live in this repo to populate the value. By itself, this is not too bad, but it adds additional complexity to the module as well as inflates the size of the database for something many may not even use.I'm thinking that a 2.0 version should drop this property from the database format and all related rules from this module.
The compressible data and ruleset would live on still, under the npm module
compressible
. Instead of delegating to this module for compressible data, it would instead be the store of all the rules (and would not even need to depend on this module).I'm opening this up for thoughts on this proposal, especially for those who are dependent on the database format. I'm not planning to make any changes for quite some time. Perhaps in a few months at the earliest, so there is plenty of time for feedback to fall here, if any.
The text was updated successfully, but these errors were encountered: