2026/01/23
|
Friday, January 23, 2026 (#23)
|
|
Fixing Connection Clades, part 1
Fixing the Process-related clades has turned into trying to understand (and rework as needed) the Connx subsystem, if that wasn't obvious, with a focus on the Plug and Socket clades.
"Plug"'s role has now been replaced by the "Jack" auxiliary clade, whose sole job is to confer the ability to connect to client and/or server objects. (On reflection, it's not clear that both would ever be needed; perhaps Plug should actually be two clades, a Client-connection and a Server-connection. I will probably revisit this.)
Meanwhile, it turns out that what "Socket" does is serve to define (1) where we are connecting (OHost()), (2) how to get in (OCred()), and (3) what object to talk to once connected (OJack(), formerly OPlug()). I think we do need a better name for this functionality, but am still trying to come up with one that is short, accurate, and evocative.
Ideas:
- "Guide": a bit overloaded (as in the sense of unofficial rules: "guidelines") and not very evocative
- "Ticket": a little more evocative, but also overloaded ("trouble ticket", "traffic ticket")
- "Key": way too overloaded (e.g.: a column-key in a data table, a credentials keypair)
- "Pass" (as in "entry pass"): too easily confused with "password"
- "Entry" (as in "entry pass"): slightly overloaded ("log entry") -- I think I'll go with this.
- "Door"? "Knob"? meh...
I think I also need to rethink how all the pieces are assembled in the config file. It currently works like this:
| cloud5 (was working) | hetz1 (partly updated, not working) |
|---|---|
#
//=====
// code-to-remote-shell:
$oHostA = HostClass::FromSpecs('cloud5.vbz.ovh');
$oCredA = new PubkeyClass('root'); // no password needed
$oConnA = ShRemClass::ForSocket();
$oSockA = new SockClass(
oHost: $oHostA,
oCred: $oCredA,
oPlug: $oConnA
);
//=====
// remote-shell-to-DB:
$oHostB = $oLocalHost;
$oCredB = new DbCredClass(
sUser: 'root',
sPass: $arPass['cloud5']
);
$oConnB = ChainClass::FromSocket($oSockA);
$oSockB = new SockClass(
oHost: $oHostB,
oCred: $oCredB,
oPlug: $oConnB
);
new MySQLCoClass(
sSlug: 'cloud5',
oSock: $oSockB,
);
|
#
//=====
// code-to-remote-shell:
$oHostA = HostClass::FromSpecs('hetz1.vbz.ovh');
$oCredA = new PubkeyClass('root'); // ssh access: no password needed
$oConnA = new ShRemClass; // driver for exec (ssh) to remote
$oDoorA = new EntryClass( // door for ssh from client to hetz1
oHost: $oHostA,
oCred: $oCredA,
oJack: $oConnA,
);
//=====
// remote-shell-to-DB:
$oHostB = $oLocalHost; // on remote: "localhost" host
$oCredB = new DbCredClass( // on remote: creds for DB engine
sUser: 'root',
sPass: $arPass['hetz1']
);
$oDoorB = new EntryClass( // on remote: door for hetz1 to run mariadb
oHost: $oHostB,
oCred: $oCredB,
oJack: $oDoorA,
);
new MariaClass(
sSlug: 'hetz1',
oDoor: $oDoorB, // code-to-engine socket
);
|
(Note that neither of these are currently working.) I'm mainly scrutinizing the fact that we have the Socket Entry as a collection of [Host + Credentials + Plug Jack], where Jack is the thing we're trying to connect to -- so why don't we initialize Jack with [Host + Credentials] instead of the other way around? As it is, we run into a problem when we need to set up the Entry for connecting from the ssh-server-endpoint (on the remote) to the DB Engine. The Entry wants [Host + Credentials + Jack], but Jack should be the DB Engine -- which needs to be constructed with the Entry object ($oDoorB): a chicken-and-egg problem. One of those two needs to be able to set up all the internal pointers for both (or maybe we don't need a pointer back from the Engine to the Entry?).