Email list hosting service & mailing list manager

Re: SRFI 170: 270 days John Cowan (06 Feb 2020 03:52 UTC)
Re: SRFI 170: 270 days Arthur A. Gleckler (06 Feb 2020 05:51 UTC)
CWD and other unresolved issues Lassi Kortela (07 Feb 2020 15:34 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 15:42 UTC)
Re: CWD and other unresolved issues Lassi Kortela (07 Feb 2020 15:47 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 18:04 UTC)
Re: CWD and other unresolved issues Arthur A. Gleckler (07 Feb 2020 18:48 UTC)
Re: CWD and other unresolved issues Per Bothner (07 Feb 2020 18:57 UTC)
(missing)
Re: CWD and other unresolved issues Per Bothner (08 Feb 2020 07:33 UTC)
Pathnames and URIs Lassi Kortela (08 Feb 2020 09:12 UTC)
Re: Pathnames and URIs Lassi Kortela (08 Feb 2020 09:20 UTC)
Re: CWD and other unresolved issues John Cowan (08 Feb 2020 18:58 UTC)
Pathname representations Lassi Kortela (07 Feb 2020 22:19 UTC)
Re: Pathname representations Per Bothner (07 Feb 2020 22:32 UTC)
Re: Pathname representations Arthur A. Gleckler (07 Feb 2020 22:36 UTC)
Re: Pathname representations Lassi Kortela (07 Feb 2020 22:50 UTC)
Re: Pathname representations John Cowan (08 Feb 2020 07:02 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 19:01 UTC)
Re: CWD and other unresolved issues Arthur A. Gleckler (07 Feb 2020 19:20 UTC)
Re: CWD and other unresolved issues Marc Feeley (07 Feb 2020 20:15 UTC)

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.