Ferreteria/v0.6/clade/Sys/Data/Engine/endpt/Server/@history

• 2024-11-19 cannibalizing old Engine stuff
  • This now combines the Def and Driver pieces into a single family.
• 2024-12-28 removing filespec-template dependencies - that should be figured externally
• 2025-01-05 Made `Creds()`, `CredsForCmd()`, and `Connx()` public so Schema can access them.
  • I considered having Engine pass those directly to the Schema object at construction time, either individually or as some sort of EngineInfo object so as to keep a close eye on interdependencies, but decided JGIW (Just Get It Working) should prevail for now.
• 2025-03-08 renaming from Engine -> DbConn for terminological consistency
• 2025-03-15 realized DoAdminRequest($oRq) is redundant if it just turns around and calls $oRq->AskEngine() -- so now I'm changing all $oDB->DoAdminRequest($oRq) calls to $oRq->AskEngine($oDB).
• 2025-05-28
  • I initially made OSocket() and OConnx() public so the Viewer could access them, but then decided they should be passed to the Viewer when it is constructed. (Where is it constructed...)
  • Renamed CredsString() -> CredsForCmd() to make it clear that this is not a Viewer/UI function.
• 2025-05-29 More substantial restructuring:
  • Renamed [WFe]Sys\Data\xDbConn -> [WFe]Sys\Data\Engine\xConn
  • Reparented from Objectorium to [WFe]Connx
• 2025-06-06 Removed references to Oper: DB Operators talk to DB Connections (sometimes via intermediary), not the other way around.
• 2025-06-08 ...but, conversely, we do need to access the Operator when all we have is the Connection, which is often the case.
  • Merged all the sets-DbOper stuff in here.
  • We also need to access the Operator on opening & closing, to pass it the Native object.
    • ...though now I'm wondering if the final opening op should be internal to Operator...
• 2026-02-04 [THINKING] I started to rebase this so it would only descend directly from StandardBase and everything else (Connx, Entry, Server) would be via ix/tx parents, and then I got confused about who descends from what.
  • Main confusion: Connx and Entry both descend directly from Aspect; I was confusing Aspect and Connx, and thinking that Entry descended from Connx (rather than Aspect, which is not used directly here).
    • ...so we either have to pick one of Connx and Entry for explicit descent (c/i), or else explicitly also descend from Aspect. That latter seems messy, so I'm just reverting to direct-descent from Entry (for now at least).
    • The only other alternative would be to create a (third) version (ixb/txb, maybe) of one of them which explicitly descends from Aspect via ix/tx, which is messy and still asymmetrical.
    • We also need to explicitly descend from ItWent (aka ItGoer), since the ix/tx version of Connx can't pass that along (without breaking convention). Wait, this is in Client, not Server...?