On 4/19/2017 12:52 AM, Warren Young wrote:
I’d call your patch “close enough.” It’s only got a 1 in 4 billion chance of
matching something incorrectly for a uniform probability distribution, and a
much smaller chance than that in practice given the bias towards text file
types in Fossil repositories.
My idea was to have a way to specify the mime type on a per-file basis. Or
maybe by file extension like the 'encoding-glob', etc. settings?
So far, the one-off policy works pretty well, since typical web browsers don’t
add new internally-viewable file types that often. With this move away from
plugins, the list of viewable file types may be *shrinking* at the moment.
I’m not rejecting the idea, I’m just calling into question its ROI.
My thinking went like this:
+ showing a PNG is neat
+ why doesn't it show an ICO?
+ make a quick little patch so it does
+ the patch is not 100% certain to ID an ICO
+ how to make it 100%?
+ a) allow one to set mime on a per-file basis
-- advantage: 100% reliable
-- disadvantage: has to be done for each applicable file
+ b) use file suffix
-- advantage: applies gobaly
-- disadvantage: applies globally & is prob. a lot more work
Since I know nothing about the internal workings of fossil, I have no
way to judge how much effort it would be.
The bottom line: this is just cosmetic so it's probably not worth
spending much effort on it. Maybe, as you mentioned, the simple patch
could be added since it would work most of the time. In addition, even
if it erred, browsers just show a broken image for an file that fails to
decode.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
