New handling for URI scheme handlers

[Jerome Leclanche]

On Sat, Dec 21, 2013 at 9:10 AM, David Faure <faure at kde.org> wrote:
> 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.

I agree, and I think we're saying the same thing here.

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

You don't trust the extension. You make a reasonable, inconsequential
assumption based on the extension. If the extension is all wrong, what
currently happens for everything... happens. As a fallback.

Funny story: I wrote a proof of concept intercepter (replacing
xdg-open) to try out the idea after I sent the last email. I then got
caught up in some other work and completely forgot about it; your
reply just reminded me of it. Turns out it's been intercepting my
clicks for the past two weeks and I wasn't even noticing *because*
it's seamless and the fallback is expected.

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

I honestly think KIO is doing it the only sensible, fully-functional
way. But KIO's solution is not interoperable with other toolkits/libs
(and I don't realistically think it can be). The advantage of what I'm
describing is that it's extremely simple to implement (as evidenced by
the working proof of concept).

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