When downloading a file, it is often not only the URL what is needed to retrieve it. A lot of sites require the session cookies and less frequently the user agent. So it would be nice to allow passing that information to the external tool.
It may be nice to have multiple options, so for example I could define an action for YouTube videos and another for PDF files.
However, I would like to support a workflow in which specific URLs are matched and the appropriate tool is selected to handle it. For example, I could open YouTube URLs directly into MPV (or similar) by just clicking on a link without even going to the "right-click > open in MPV" menu.
This has the problem that sometimes the URL is not enough, you need to determine other things. For example, the server may reply that the URL I just clicked on is in fact a PDF. It would be nice to be able to tell Dillo to download the file and open it in my PDF viewer *after* the server has replied with the MIME type. It should be posible to directly pipe the server reply into the tool, no need to wait for the download to finish.
Now, going back to your specific case, it may be good to have a simpler solution first that can later be extended to the more general approach, so we don't have to wait too long.
I have some ideas of how to do it, but I would like to ask you to give concrete examples of that feature so I can test it with those programs.
For me, it could be a number of filetypes, plus things like youtube or other media links. These would be opened in various programs. Obviously, many programs can't directly open a URL and will fail. Why not just have 3 generic options and let the user decide: link_handler_1="" link_handler_2="" link_handler_3="" or whatever name is more suitable. If the option is undefined, it doesn't show up in the link menu. Even if there was only one handler option, personally I would just have it call a shell script which parses the URL and extension and takes appropriate action. This doesn't have to be a 'one size fits all' feature, and I think most Dillo users are advanced enough to use this to their advantage. Your ideas above regarding Dillo handling the logic for various file and content types are excellent, and also complicated :) But, these can be two separate features, with optional external link handlers acting as an override for the built-in handling.
A similar feature has been implemented in dilloNG:
https://github.com/w00fpack/dilloNG/commit/7bd6b1c4592466d6e717eaf795e98b7ce...
But as it is currently implemented is not very extensible, only a "media player" and a "media downloader" options are posible.
Thanks for pointing this out, looks like a good template for testing. If it works well, I'll post a demo patch for anyone interested. Regards, Alex