On Mon, Dec 2, 2013 at 7:57 AM, Bastien Nocera <[email protected]> wrote: > On Mon, 2013-12-02 at 07:49 +0000, Jerome Leclanche wrote: >> On Mon, Dec 2, 2013 at 7:13 AM, Bastien Nocera <[email protected]> wrote: >> > On Mon, 2013-12-02 at 00:59 +0100, David Faure wrote: >> >> (very old mail, but this is bugging me again :) >> >> >> >> Context: I believe that associating a webbrowser with >> >> x-scheme-handler/http is >> >> wrong. >> >> >> >> On Wednesday 06 October 2010 00:38:40 Bastien Nocera wrote: >> >> > David Faure wrote: >> >> > > When you click a http URL that >> >> > > points to an .odt document, you want to launch openoffice, not a >> >> > > web-browser. >> >> > >> >> > If you're already in a web browser, yes, but in this case, the lookup >> >> > shouldn't be including a scheme handler lookup, just an application that >> >> > handles that particular mime-type. >> >> >> >> But what if you're not in a webbrowser in the first place? >> >> E.g. in a desktop email application, you click on an HTTP link to a .odt >> >> document. Should that really start firefox, just so that it can then >> >> launch >> >> openoffice? >> >> (same with any other content application that can handle HTTP urls on its >> >> own; >> >> same with other schemes that apps might support, like FTP). >> >> >> >> Note that at this point we have no clue about the mimetype. We can start a >> >> download and find it out, but the first question is: should we do that, or >> >> just blindly trust the app that says it wants all URLs with this scheme >> >> (http, >> >> in my example). >> >> >> >> Since we don't want this to happen in KDE, I had to write code such as >> >> "if KIO >> >> supports a scheme and an app exists for the mimetype x-scheme- >> >> handler/<scheme>, then give priority to KIO". (for the special case of >> >> http, >> >> there is actually a user setting for "send all http urls to this >> >> particular >> >> app", but that's not the default setting). >> >> I don't like it very much though, it feels like a hack :) >> >> But I guess it makes sense, since in KDE we prefer to open HTTP urls by >> >> mimetype, while IIUC in Gnome you prefer to open them with a single >> >> scheme- >> >> associated application (i.e. webbrowser). >> >> >> >> So, it's all fine, I'm just curious about what happens in your case when >> >> the >> >> user isn't in a webbrowser in the first place (and to pick the worst case >> >> - if >> >> it's not running yet, which means a long delay coming from the startup of >> >> two >> >> large applications one after the other). >> > >> > I wish it worked like that as well, but you've just broken one-time URLs >> > and tried to open a login page in LibreOffice if you don't share cookie >> > jars between all the clients. >> >> With a middleman client this is a solved issue; it would be identified >> as a page to take care of in the browser. > > Let me know when you have that middle man client implemented :) > > I wonder how you'll handover to the dozen of different web browsers, > read their cookie jars, or get applications with links to use your > middle man client instead of whatever HTTP library they want to use. > > It's a nice idea, but it's just not feasible without a clean slate. I > think that GNOME's current approach is more pragmatic, especially with > HTTP's baggage. >
I think you're confused about the complexity of the task. All the client does is, for http: - Parse the url given to it - Identify whether it's potentially a file through its name (get a filename if there's one) - If it is, run a match against the xdg patterns on it - If there's any match that is not an app that is associated with x-scheme-handler/http(s), do HTTP HEAD on the url - If the HEAD was successful and returns a mime type in the mime type db and the mime type is associated with an app, *download* the file -> Hand off downloaded file to the associated app * If any step fails, hand off to web browser This could be a simple script, or it could be a more involved download manager that would integrate with the desktop (a neat system-wide download bar such and such). J. Leclanche _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
