From: John Cowan <xxxxxx@ccil.org>
Date: Friday, November 01, 2019 9:19 PM
Agreed, essential for efficient logging of most types (you could in theory rename and copy the old file first, but...
That doesn't work if two processes are appending at the same time (which is guaranteed to work with O_APPEND).
I keep forgetting that use case is the only reason O_APPEND exists. But to continue my half-thought about the absolute necessity of it for this proto-SRFI, you could in theory have each process write to its own file, and merge them later.
To support this use case, you'll have to be able to write a complete item through a port al la write(2), no buffering that might result in multiple writes that could then get interleaved with those from another process, which is satisfied below.
[...]
k) posix-permissions (when a file is created, what permissions to use; this is _not_ equivalent to creating with one set of permissions and then changing them).
How essential for security??
If you open a new file with a mode that forbids writing, you can still write on it, but nobody else can.
That gets pretty close to "absolutely essential".
[...]
Cygwin goes to a lot of trouble to let process select() on both sockets and files. On reflection, though, this will be needed for processes too, so it may need to be a separate SRFI.
Again I mention the concept of isolating all added needed port magic to the minimum number of SRFIs, see below.
I have a new idea, though:
Provide an open-file procedure, which accepts a pathname and the following keys: append, create, truncate, exclusive, buffer, and posix-permissions, and then returns a fd, which you can then transform into a port with the SRFI-170 fdes->port procedures. This only requires a simple FFI.
As far as I know, raw POSIX file descriptors don't have the sort of buffering we're desiring, they have none at all.
This option assumes someone will also be implementing that part of SRFI-170, which also requires messing with your port implementation.
Does this work for Windows?
The other keys, namely bidirectional, char-buffer, encoding, newline, and encoding-error, are relevant only to textual ports,
Bidirectional raw for databases isn't useful??
so they would only make sense on open-input-file, open-output-file, fdes->textual-input-port, and fdes->textual-output-port. This is logically part of SRFI 170, but until we know whether keywords are in or out, we can't integrate it satisfactorily.
We can probably wait for the keyword SRFI to be finished.
What's more, it involves deeper integration with the implementation's ports than anything in SRFI 170. So keep it separate for the present.
Contra what you said, it's not having a minimal number of non-portable SRFIs that matters. Splitting a SRFI up doesn't make things harder, it may even make them easier.
Breaking up the work into smaller blocks has its obvious advantages, but when getting into something that gnarly I prefer to do it all at once, however it's sequenced. Given that a implementor may have to change the architecture of their port implementation, it's best that they have as few sets of requirements as possible before they start, ideally there would be only one.
- Harold