Re: [Ayatana] Opening URL's that point at downloadable objects

[Luke Benstead <kazade@xxxxxxxxx>]

Hi Jeremy,

I think trying to *fix* this situation would be potentially very hard, if not impossible, to do robustly and correctly. Of course, the reason that clicking a link opens the web browser is that the browser handles the http:// protocol, just as it may also handle https:// ftp:// and potentially others. 

Say for example we changed this to what you suggest, and that clicking an http:// or ftp:// link would first grab the file header, read the mime-type, and then open the correctly assigned application, what would control the download process? It's not a simple as just opening it, obviously if the file was very large, or the connection very slow, there would need to be some way to cancel the action. So we'd likely need an application for that, perhaps we can use gvfs and Gnome's built in download manager. But this still blurs the line of what should be handling what. I assume that if you were browsing using the web browser, then the browser would have the opportunity to handle the mime type first before passing it onto the system, otherwise the Internet just wouldn't work.

I'd argue that we are looking to fix this in the wrong place, really we should be fixing this in the browser. The web browser is already set up to consistently handle the protocols assigned with it (along with detecting unsafe sites, invalid SSL certificates etc.) The only problem is that the browser is opening up an entire instance (or new tab/window) to download the file; this is totally unnecessary. 

It would be far simpler, more robust, and more cross-desktop compatible to fix the browser so that it checks the mime-type first before opening a window, if it's not a mime-type it can handle it should popup the open/save dialog only. Everything from that point on would behave as it currently does, with the exception that if the browser process had only spawned to download that file, then it would exit and if that was the case, there never would have been a browser window open, just the open/save dialog and the download dialog.

Luke.

On 3 June 2010 18:24, Jeremy Nickurak <jeremy@xxxxxxxxxxx> wrote:

Here's a UI experience pet peeve I'd be curious to hear some feedback about, especially with regards to whether it's confusing/unintuitive to a regular user:

You're in an application, maybe an email client, or an IM conversation, or (heaven-forbid) a terminal. There's a URL you'd like to click on, that goes to a PDF, .zip archive, or any other file that's not actually going to be viewable in a web browser. You click it.

What should happen? It'd be nice to see the content open up in the correct application. We have application and content preferences for this sort of thing. We can look at mime times, in particular.

What happens? A web browser window opens, with no content, and then the WEB BROWSER opens the http connection to the content you asked for, and then downloads it or streams it to another application.

Is this by design? Or would it make more sense for the desktop to poke the web server, get the mime-type of the content, and then open the relevant app? The desktop could even download the content, and continue streaming it to the application...

There's a catch that this requires 2 http connections, one to check the type of the content, and then one to open it. However, I'd argue that this type of interaction isn't going to be making so many connections that that would be a bottleneck in any way, or even likely a noticable delay in most cases (certainly not more than the delay of opening a web browser window). If it was critical, the double-connection issues could be addressed with a little clever proxy work...

Thoughts?

--
Jeremy Nickurak -= Email/XMPP: jeremy@xxxxxxxxxxx =-

_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp