New handling for URI scheme handlers

[David Faure]

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 
cases.

> [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 
broken.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5