Hi all, Responding briefly, because I won't have too much time to dig into the details.
On Mon, Jan 6, 2020 at 10:46 PM Bruno Haible <[email protected]> wrote: > - The 'grep' program shows references into disk files. When the > user selects one of these references, a text editor opens the > referenced file at the particular line. This (opening a text file at a particular line, maybe column as well) is the only feature missing from the hyperlink protocol that users are asking for. See the comments at the gist. We spent some time trying to find the right solution, but it's not easy. Other tools, most notably gcc and friends would also highly benefit from this feature. If you aim to fix this, that would be highly appreciated! Two bits are missing. One is: How to denote the line in the hyperlink. Either make it part of the URL (e.g. #L1234, a notation often seen on web VCS frontends), or pass it as another field in the OSC 8 protocol, that is, outside of the URL. Both approaches have pros and cons, again, read the gist's comments for more info. The other missing bit is: How to launch the corresponding app? This again has at least two levels: the desktop file and the supporting code. There's no slot for the line number in the existing infrastructure, e.g. corresponding parameter in .desktop files, so a terminal emulator on Linux would figure out its own way of opening the app, not integrating with the rest of the desktop (e.g. would need to offer its own config for the user's favorite editor). But, luckily, this xdg mailing list is the right place to address this. The desktop file should be extended to support a line offset (and maybe character too, but see the gist comments for problems with that). Then the next question is: how to open it from existing toolkits, e.g. how would you pass the external line number (if that's the answer to the previous paragraph's question) to gtk_show_uri() or similar toolkits' corresponding methods; would GTK and other developers accept a new method taking an additional parameter? All this can (and should) be addressed _within_ the already existing frameworks of .desktop files, file:// protocol and so on; inventing something brand new for this sounds a really bad idea to me. The scheme could also be extended to time offset within a media file, track on an audio CD, page number within a doc/pdf and so on, although there's probably hardly any demand for these. (And seriously, who uses audio CDs in computers anymore?) > When the hostname is equal to the machine's gethostname(), the > application should be started on that machine, without using network > protocols. And when the hostname is different... Trying to connect to that hostname is potentially highly problematic. It might work in simple setups, but not if there are firewall rules, proxying / load balancing rules, if the server was reached via multiple hops, and so on. Also note that most apps place the short hostname in file:// URLs because that's what hostname() returns on many distros, and this is a concept that belongs to the host itself, whereas the FQDN is subject to name resolution and such, and a host might have multiple FQDNs, or one per network interface etc., it's not easy to find one (let alone a canonical) fqdn, and there's absolutely no guarantee others might locate the host based on this. Your other proposal is also problematic about listening: what if you're not allowed to listen on that port? What if another user already listens there? Also I can't help notice that there's absolutely no security involved in your protocols. Like, could anyone just connect there and ask to run a certain app? The current hyperlink behavior, including its security model, deliberately follows what the web already does. It would be a conceptual mistake to diverge from it, including building up connections that the user doesn't expect. > Why an apptype? Why not directly include the application name in > the URI? Because the user may want to customize things: > - Different text editors exist. > - Different audio players exist. > - Different PO file editors exist. No, not because of these reasons, but because of way more essential security. Many times you can't control the message that gets printed to the terminal; you might 'cat' a file you receive from an untrusted source, or a buggy software might print raw data received from an untrusted source, or you might ssh into a compromised server, and so on. The data that arrives to your terminal is not guaranteed to be safe, yet the experience of using the terminal must be safe. Your proposal opens up the door for someone to inject a link into my terminal which, should I ctrl+click on it, would locally wipe out my files, or upload my potentially sensitive/confidential data to the attacker's site. Such design is unacceptable. I'm afraid that with your two proposals, you're trying address problems that don't exist, as well as 1 actual problem where you take a wrong approach. The existing 1 problem should be addressed inside the familiar concepts, tools, protocols, file formats and security model, and not by inventing something brand new that doesn't even remotely resemble what we already have. regards, egmont _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
