The whole Channel thing

[Jose E. Marchesi]

> Jose and list,
>
> On Sat, Feb 7, 2026 at 4:13 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>> For me, I found the notion "a channel represents a physical device"
>> confusing until I realized it should not be understood as "a physical
>> device is represented by a single channel".
>>
>> I look at channels as ways to acccess books in physical devices, or
>> "modes" of access.
>>
>> For example,
>>
>>    stand_in_channel
>>    stand_back_channel
>>    stand_out_channel
>>
>> are all channels giving access to the same physical device: the
>> _filestore_.  In POSIX systems that is the hierarchy of filesystem
>> rooted at / and covers books like actual files stored in a filesystem on
>> some partition, character devices, /proc, etc.
>>
>> Using stand_in_channel, stand_back_channel and stand_out_channel
>> determines then not only the physical device (the filestore in all three
>> cases) but the "mode" of accessing the desired book: in read-only mode,
>> in read-write mode, in write-only mode.
>>
>> The idfs used in all three channels are filestore names, i.e. file paths
>> such as /foo/bar, /dev/null or `foo.o'.
>>
>> Then, you can have other channels that represent othe physical devices
>> that are not the filestore.  The collection in QAD is very interesting:
>>
>> stand_env_channel provides access to the environment of the runnign
>> process, which is _not_ the filestore.  The represented physical device
>> is the auxv array passed to _start by the kernel, and having it as a
>> channel allows to transput on the auxv array entreis (these are the
>> books) using the same interface than to files in the filestore.  The
>> idfs in this case are the names of the enviroment variables, PATH, HOME,
>> etc.
>>
>> A www_channel could represent the WWW.  The books would be the URIs you
>> use in http get and post operations.
>>
>> etc etc
>>
>> I think it is a nice abstraction.  Transput means interchanging data
>> with all sort of "external" devices, and not everythig is the filestore,
>> not even in Unix.
>>
>
> I like the eloquence of your argument and the points you make.  Just a few
> minor comments:
>
> - the environment is in fact available in the filesystem, at least in
> Linux, at /proc/PID/environ; I have no idea whether writing to it is
> effective in some way or the other;

I have never tried to write these files.  C programs use getenv/setenv.

> - in terms of handling something like web content, maybe a productive line
> of thinking could consider the idf as a URI? which would open interesting
> avenues for exploration of other protocols than http and https;

Yes, definitely.

> - in terms of "not everything is a file", in Plan 9 everything is in fact a
> file; I'm not suggesting that we should retarget to Plan 9 however.
>
> Anyway, given your two sets of comments, and also those by Paul Leyland
> (separate), looking to QAD for additional guidance (beyond van Vliet) is
> good, and I think that's very helpful.
>
> Also, for the time being at least, it's reasonable to expect the standard
> prelude to define all necessary channels.
>
> And finally, for a first cut at things, a reasonable set of channels to
> provide is:
>
> - stand_in_channel; (read only)
> - stand_out_channel; (write only)
> - stand_back_channel; (read or write)
> - stand_err_channel; (write only)
>
> Any objections?

Why stand_err_channel?

I would expect standerr to be a standard File opened through
stand_out_channel...