On Sat, Dec 21, 2013 at 9:10 AM, David Faure <[email protected]> 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, [email protected], http://www.davidfaure.fr > Working on KDE, in particular KDE Frameworks 5 > _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
