URL and application handling/registration standard

[Bastien Nocera]

On Sun, 2012-09-30 at 00:38 +0100, 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.
> Confusion can arise if the image format is not supported by the image
> viewer, too (but still registered); it would forward back and forth
> between browser and image viewer.
>  - The reverse has to be supported:
> http://example.com/image/?id=12345. This cannot be guessed by name, it
> has to be sniffed. Most likely scenario is it'll get opened in a web
> browser always.
> 
> 
> This is just for http; some protocols are much more obscure about all
> this. And you have to remember not to go overboard when "integrating"
> it, for users will likely want to disable this behaviour (and always
> open such and such protocol in a specific program, 

Feel free to read the archives of this mailing-list to know why adding a
list of protocols isn't a good idea, and actually harms
interoperability.