2026/09/01
|
Tuesday, September 1, 2026 (#244)
|
|
Main Work
Currently doing a careful re-think of how Ferreteria connection-sessions are structured.
Despite the table currently claiming that the Starter does proc_open() and proc_close(), it is actually the Session doing that. I'm thinking this is part of the problem I'm currently dealing with.
What if we have (as originally laid out on 2026/08/31):
- create connection object
- open the connection
- for each command over the same connection:
- open a stream to receive responses
- send the command
- read the responses
- [send additional requests]
- [receive additional responses]
- close the stream
- close the connection
Current table (to be modified):
| Details: | API | Proc | SSH2 | ||
|---|---|---|---|---|---|
| Model Action | Starter
|
Session
|
Starter
|
Session
| |
| Open | Session->Connectify()
|
NO OP | create Session object | ssh2_connect()
| |
| Run | Session->StartProcess() | proc_open()
|
send to stdin |
forward to Session object | ssh2_exec()
|
| recv | Session->OExecLecture | stdout | |||
| send | Session->OExecRespond | stdin | |||
| Shut | Session->ActualShut() | proc_close() |
zap Session object | ssh2_disconnect()
| |
In retrospect, looking at the description, I think I created Starter after only looking at running local processes, and then tried to shoehorn SSH processes into the same framework without really reconsidering what the framework and naming should be.
...or maybe I did reconsider, but just didn't have a good enough understanding of how all the proc and ssh2 pieces fit together.
What if:
- Starter becomes the connection (no-op for local stuff)
- Session
- sends stuff over a connection
- handles response data
- can include nested sessions for dialog within an executable (e.g. the outside session opens MariaDB, and the inside one runs SQL admin commands).
- ...though if we're doing SQL, shouldn't we just be using the proper binary-connection library (mysqli, PDO, whatever is best)? Since we've gotten this far, though, maybe it makes sense to get it working this way first, then later refine it to have the option of communicating via the library instead.
Tentatively, this means that:
- a Starter is actually a special kind of Session that manages a connection -- so Starter needs to be a podling of Session, and everywhere Session requires a Starter interface, we can probably change that to a Session interface.
- any Session can create another session from a Command -- so those fx get moved from Starter to Session.
Unfortunately, under Session we already have the different connection types -- so we're already using hierarchy for that. Maybe this is where we farm out the connection-details to a Core object, and possibly use the wrapper classes I wrote to allow easy swapping between native and PSL libraries? (see: Sys\InOut\Connx\Server\SSH2)