2026/02/27

Friday, February 27, 2026 (#58)

Thursday Friday Saturday posts: prev < this > next

Emerging from yesterday's Thinking about Convey, what I worked out is that it should be able to function sort of like a Cable but for connecting stream-pairs (input and output) together. You can then configure however many of these you need in order to make sure everything gets where it needs to go, and loop through polling each one of them in sequence until the process is done (and all receive-buffers have been emptied).

The next piece of the puzzle: it seems clear-ish that the creation of Convey objects needs to take place inside the Runner classes, because the native libraries each have different ways of presenting the streams they create (and different sets of streams they make available).

This in turn opens the question of: how do we get the streams all the way from the Runner at the end of the Cable-chain all the way back to the endpoint-Client which needs to process it? The answer (I realize as soon as I formulate the question) is that we already put all the Stream info into the Command object -- so all we need to do is replace or supplement that with the Convey-object list/array (and there's probably some way that APipes figures into this).

Much Later

Code modifications:

• Moved Connx/aux/APipes into Connx/aux/A/Pool, where /A/ (for "array") will be a folder for lists of things.
  • ...and Connx/aux/APipes/APipesProc became Connx/aux/A/Pool/Pipes, which is hopefully not a worse name.
• Created Connx/aux/A/Canals for managing lists of Convey (to be renamed Canal obviously-ish) objects.
• Moved all the Connx/aux/Q* clades (QCable, QClient, QServer, QStream into Connx/aux/Q/*, to help reduce clutter. Managed not to break exports!
  • Kate insists that Connx/aux/QStream is still a thing, albeit empty; I spent several minutes trying to get rid of it, without success.
• Made a copy of ...Connx\Runner\Local\cProc::DoCommand() to start modifying for use with Canals.

I think the design-question with which I'm now confronted is: how is that actually going to work...

Terminology Note

I found that "input" and "output" somehow end up being ambiguous in some contexts: does "input" mean something I read input from, or a place where I send my input? Is "output" something I write to, or something else generating output that I read from? What I finally came up with is Lecturer and Listener (or Audience, sometimes):

• Lecturer is a stream from which you receive data
• Listener is a thing that receives data from you

That said, sometimes it feels cognitively easier to talk in terms of "source" (srce) and "destination" (dest), when moving bytes from one stream to another; in others, it makes more sense to talk about "receiving" (recv) and "sending" (send) or "reading" and "writing". There's no single pair of terms that seems to be universally unambiguous, so I try to choose vocabulary carefully for each new context.

I think the following is how all of these terms correspond, but I feel like in some circumstances some of them are reversed (will make a proper page about these, if this happens):

FROM	TO
input	output
read	write
source	destination
receive	send
you receive/read from an input source	you send/write to an output destination
lecture[r]	listen[er]

...where "you" means "the code you are writing".