2026/09/04

Friday, September 4, 2026 (#247)

Thursday Friday Saturday

References 2026/09/03 (← links) Ferreteria/v0.6/clade/IO/Aspect/Connx/run/Session/@code/cur/2026/09/04 (← links) 2026/09/05 (← links)

Main Work

a careful re-think of how Ferreteria connection-sessions are structured

The current tidying (continuing yesterday's reorganization):

• When running a "Main" Command, there is typically going to be an SQL sub-command to be sent within the Main Command's Session.
  • Q1. If the plan is to replace Session->DoCommand(<command object>) with Session->DoCommand(), on the theory that each Session object is tied to a single Command object, what should the steps/syntax be for sending the SQL sub-command?
  • Q2. If each Session object is tied to a single Command object, why are they even separate objects/clades?
    • A2. Presumably it makes sense to leave them that way because they have different parent-clades: base\Standard ⇒ IO\Aspect\Connx\run\Session vs. base\Standard ⇒ IO\Aspect ⇒ Sys\InOut\Connx ⇒ IO\Aspect\Connx\run\Command – so, hmm, kinda not; Session is basically a standalone. But...
      • We don't want Session to be under Command, because Command has its own hierarchy. Session does currently have one subclade, Starter. Although it's not clear if Starter is even needed, we haven't resolved that yet. Conclusion (for now): it looks like there's no obvious way to join them, and no obvious need to do so.

Q1 investigation

Currently, DoCommand() does these things:

• sets the Command's Session object
  • (formerly: sets the Session's Command object)
• deploys the Command's Updater object
• sends Updater an OnBefore() event
• transmits the command (SendCommand())
• loops to check for output from the command-process until it's done
• sends Updater an OnAfter() event
• closes Stream object the variable for this object is now never set

Maybe the thing to do is have DoCommand() accept an optional Command parameter. If it's set, then it does what it used to do (but also saving the current Updater, if any, and restoring it afterwards); if one isn't set, then it just uses the Session's assigned Command.

• ...but in that case, what is even the point of having one assigned?
  • This may have something to do with deciding that the Command object should (where applicable) provide the Connection object...
    • ...which was done because of not wanting the Session to be tied to the Engine class...
      • ...which is where the configuration currently puts the Connection object.
        • ...which makes sense, because we need to know how to talk to the Engine that we're configuring.
        • ...but maybe Engine should have a Server interface, and the Session can have a property for Server objects?
        • Note that the Engine (and its auxiliary objects) is what's invoking the Session in the first place -- but it could conceivably be some other kind of thing... unless "Engine" isn't just databases but other types of remote services...

Okay. So. If we think of an "Engine" as being more like, I dunno, a process-controller -- doing the high-level operations, with the operational details being delegated to situation-specific client, server, and connection objects...

Following that model:

• Engine creates Session, passing Connection to it
  • In theory (and possibly if there are future operations where we do more complicated stuff involving more than one remote server?), the Engine could have more than one Connection object and more than one Session. Any given Session object doesn't need to know that; it's given a single Connection to use for its operations.
• Engine sets up operation-specific Streams and provisions the Session with them.
• Engine tells the Session to open (connect).
  • If we're going to be running more than one Command, the outer process can tell the Session to open, and that will keep it actually-open even while the Engine is opening and closing it for each Command.
• Engine tells the Session to run a Command (via DoCommand()).
  • Session->DoCommand() will also run the I/O loop until the Command is done sending/executing.
• Engine tells the Session to close.
• Engine does any necessary processing of data received into buffers. This includes:
  • requested data, if not large enough to need processing as it is received.
  • error messages, if any
• Engine shuts the operation-Streams.