Expected behaviour
When opening a file with an external tool or a Ruby lib, we should, depending on the file content_type, be able to use read OR streaming for better performance.
This will blend well with #404 and #405.
Also, we should place a (user customisable) hard cap on the allowed file size for certain content_types, e.g. we do not want to try to open a 10 GB csv file unless authorized explicity in the validator (or globally for said content_type) by the dev.
The customisation could be done by validator using the size validator. If the user has set a size limit we can use it, this would actually be smart?
Allowing a user overwrite by validator or globally will mitigate the potential issues of the gem setting the content_type size threshold too low/high.
This is a much trickier issue, since size threshold values will be set arbitrarily by the gem.
To not forget
- Update the readme accordingly
- Make the size limit errors the same as
size validator
Expected behaviour
When opening a file with an external tool or a Ruby lib, we should, depending on the file content_type, be able to use read OR streaming for better performance.
This will blend well with #404 and #405.
Also, we should place a (user customisable) hard cap on the allowed file size for certain content_types, e.g. we do not want to try to open a 10 GB csv file unless authorized explicity in the validator (or globally for said content_type) by the dev.
The customisation could be done by validator using the
sizevalidator. If the user has set a size limit we can use it, this would actually be smart?Allowing a user overwrite by validator or globally will mitigate the potential issues of the gem setting the content_type size threshold too low/high.
This is a much trickier issue, since size threshold values will be set arbitrarily by the gem.
To not forget
sizevalidator