Ferreteria/v0.6/sys/Connx/run

Ferreteria: process-management subsystem

About

• Purpose: We need to have an abstract model for running executables in different contexts (mainly: local vs. remote, where the latter mainly means "via ssh"), so that the control-code doesn't need to know anything about where the executable is.

History

• 2026-03-27 Adapted from end-of-day notes on 2026/03/26.

Process Control Modeling

Two different approaches:

• In SSH2, you first open the session (ssh2_connect()) to get a session-resource, and then you send commands (ssh2_exec()) via that resource.
  • You can also open a shell (ssh2_shell()) for further commands, though it's unclear what the difference is.
• In proc, a process starts with a command. The command can then be left running to receive additional data, which will be interpreted by the initial command.

I'm still trying to figure out a model-wrapper that will correctly handle both of these. The required pieces seem to be:

• (hook) Open the object
• (object) Initial command
• (object) Lecture-stream (for the process to send data)
• (object) Listen-stream (for the process to receive data)
• (hook) Shut the object

The most awkward fit is the "initial command". On ssh2, every command sent via an open connection is an "initial" command.

Maybe the trick here is... to think in terms of different levels of nesting. My first attempt to map the model to the fx calls:

Model Piece	Action: Proc	Action: SSH2
Open	NO OP	ssh2_connect()
Command	proc_open()	ssh2_exec()
Shut	NO OP	ssh2_​disconnect()

After thinking about that for a bit, I think maybe what I need is actually two models/clades:

• Process runner: handles creation of process session objects
• Process session: handles individual processes, including termination and (where available) status

So: in each case (Proc and SSH2):

• create/provision Runner object
• open it (which will be a NO OP for Proc)
• use it to run commands, each of which creates a Session
• each Session has status info and can be closed