New handling for URI scheme handlers
faure at kde.org
Sat Dec 21 01:10:34 PST 2013
On Tuesday 03 December 2013 09:10:55 Jerome Leclanche wrote:
> This is no different than using the mime db to only match by name and
> not content because of performance concerns. As we all know, foo.txt
> may as well be an application/zip, but it's rare enough that it
> doesn't warrant reading everything just to display a file type. It
> only becomes.
[last sentence was truncated?]
I disagree: if foo.txt is a zip file, but the user named it foo.txt, then we
treat it as a text file, at least in file managers (a ZIP application might
want to use content-matching instead, once we open the file there).
This gives full power to the user, and is necessary since some magic-matching
isn't fully reliable. The main point is: if the user wants to fix a wrongly
named file, he/she can.
However trusting extensions in an HTTP URL is completely wrong, I gave
examples already. And this is something the user cannot do anything to fix.
You say it works in 99% of the cases, I say
1) this number is smaller
2) any number that is not 100% means bugs, i.e. bug reports and unhappy users.
You cannot design solutions that sometimes break, in perfectly valid use
> [rendering while downloading to a temp file]
> Of course it's a different concern for other file types.
So there again it's not a fully working solution, unless the application
itself decides on the approach (incremental rendering or full download first).
This is exactly what we do in KIO. Doing it outside the app will lead to all
the bugs you mentionned (broken images, text editors warning of outside
changes, etc.). As you yourself pointed out, this would just be completely
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
More information about the xdg