URL and application handling/registration standard

[David Faure]

On Sunday 30 September 2012 00:38:39 Jerome Leclanche wrote:
> There are a lot of issues with coming up with a good system for this.
> 
> Say you get a uri to an image: http://example.com/image.png. You want that
> uri to open in an image viewer that supports http.
> 
>  - What happens if the uri isn't an image? It should instead be opened in a
> browser. But xdg-open cannot know how to open and sniff arbitrary
> protocols, so it either has to open in an http reader *first* that then
> forwards it to an image viewer, or the image viewer has to understand a lot
> more about the protocol than might be implemented. 

Or xdg-open calls kde-open, which actually "opens and sniffs supported 
protocols" before deciding which application to open the file with.
The browser and the image viewer don't need any special logic for this
(they just open the same URL, and the underlying VFS called KIO is able to 
hand out the same connection to the application).

>  - The reverse has to be supported: http://example.com/image/?id=12345.
> This cannot be guessed by name, it has to be sniffed.

With HTTP you can *never* guess by name.
http://example.com/cgi-bin/script.pl will likely not return a perl script to 
you, despite the apparently-known extension.

> (and always open such and such protocol in a specific program,

*That* is what x-scheme-handler is for. To disable the above per-mimetype 
associations and skip to "always open this protocol with this app".

> Now the question becomes: How can you open an arbitrary uri in an arbitrary
> program that supports the uri's protocol, without breaking everything or
> having to fire 2-3 programs successively?

x-scheme-handler/protocol.

> Better solution yet, imho: Screw being too clever.
>  - Have apps list protocols they support. Eg
> Protocols=x-scheme-handler/http;x-scheme-handler/https;

Never ever do this, for the reasons above. HTTP is too complex to send all 
http urls to a single app.

> For that reason alone I would be in favour of recommending adding an
> official, yet unused Protocols key to .desktop files, that would list
> protocols a program is able to deal with if given a link to *content*
> through it. If fdo ever gets around to having a real spec for all this,
> that large part of the work will have already been done.

Saw that you got a "no" to that. Welcome to the club.

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