Choosing an application to open URLs

[j.g.karssenberg at student.utwente.nl]

Hi,
 
[This mail relates to te topic started by Patrice Dumas and results from a private discussion.]
 
The problem at hand is how to determine the right application when given a URL to open. Several approaches for this were discussed here in the past, including pseudo-mimetype schemes and the usage of various VFS systems. Below I describe an aproach I intend to use in my own applications and which I intend to offer as an extension in my MimeInfo perl module.
 
I would like to distinguise two types of schemes that use an URL (or URI). The first are storage protocols like ftp, smb etc. For these protocols the VFS approach works very well. It is possible to do a glob match to determine the mimetype and determine the application. Then one can check if the application uses VFS natively (does the Exec key in the desktop file contain %u ?) and if not download it or use a Fuse mountpoint. (We can also access the VFS to get magic mimetype or ask the VFS for info).
 
However there is a second type of URLs that do not behave like this. These are cases where the scheme specifies the program to use and not the transfer protocol. I would like to call these application schemes. Examples of these are mailto, nttp etc. For this type of schemes one could very well use a pseudo-mimetype, e.g. "x-url/mailto". For this class of protocols an extra key in the .desktop file which is similar to the Mimetype key would also work. I would prefer adding this key, but as a short term solutoin the pseudo-mimetype will do.
 
Now the problem is that the protocol used most of the time is used in both modes, this is of course http. When I get a http url it can be either a link to e.g. a pdf file that I can access through VFS or a link to an interactive website that I can view in a browser, this website will not be the same when I download it first. Also it can be observed that using globs to determine the filetype of a http URL often gives wrong results. An url ending in ".pdf" can as well be a pdf as a html page telling you that "download should start shortly". The only good way I can think of to get a file type for a http URL is doing a HEAD request to the server. When this returns "text/html" I consider I treat it like a URL for an application protocol and use "x-url/http" to find the webbrowser. When it returns another file type I consider it an URL for a storage protocol and go for the VFS/download approach. (If the request fails because I'm offline or there is some other error defaulting to "x-url/http" seems the save choice.)
 
My first implementation will work within the framework of the existing XDG specs. However I would like your feedback on this way of handling URLs. Also I would propose an extensions to the freedesktop spec similar to what Patrice describes:
 
The desktop file should contain a key "Scheme" which is analogue to the "Mimetype" key. This key can e.g. specify for an email client that it is able to open "mailto" URLs. This key should _not_ be used for protocols the application can handle by virtue of using a VFS layer. For this key there should be a cache file with scheme to application mappings and a list of prefered applications, just as for the MimeInfo key. 
 
Also there should be a global list with protocols that are supported as storage locations by the local VFS. Any protocol not in this list can be considered an application protocol. Since there is no standardized VFS at the moment and we can mix e.g. Gnome applications with KDE applications it will be difficult to make a detailed list that is correct in all cases. Matters are complicated further because the same application could have compile time or even run time options for different VFS layers. Consider this list a requirement for when a consensus is reached on how to do a VFS for all desktops. For now I will just use a list of the protocols supported by my download library.
 
Thank you for reading such a long post and please let me know your ideas on this problem space.
 
Regards,
 
Jaap Karssenberg <pardus at cpan.org>