Re: Pathnames and URIs Lassi Kortela 08 Feb 2020 09:20 UTC
> There are important security and performance implications to opening a > URI in place of a file. I've found generic URI opening useful mainly in > simple scripts. If any `open` call in a complex application can turn > into a `open-uri`, a security audit is difficult. This could probably be mitigated by having a (path-remote? <path>) predicate. Then open-file procedures and the like could ensure a non-remote path. Another point of concern is that many programs want to present a simple interface to the outside world. APIs in the programming language that accept fancy syntax (such as file: URIs in place of filenames) make this difficult to ensure: e.g. a program reading a filename from a metadata file will now be able to read URIs. Some other program reading the same metadata file may not work with those URIs, supporting only traditional filenames. A similar problem is things like the ISO/POSIX C string->number functions being lenient with leading zeros, whitespace and radix prefixes. It's difficult to "just parse some digits" with C. Extensible config parsing / logging frameworks now present similar interoperability worries: e.g. CosmicConfig and Dhall are difficult to replicate in another language.