2026/01/24
|
Saturday, January 24, 2026 (#24)
|
|
Fixing Connection Clades, part 2
The first question I considered in more depth is: does the connection need to be two-way (and if so, why)?
Partial answer: looking just at the DB Engine code, it both initiates actions and handles how they are communicated to the engine. Possibly what we need to do is separate those pieces so the former is entirely in the Oper clades and the latter is entirely in the Conn clades -- but there are specialized operations which we wouldn't want the intermediate connection clades to have to support. Maybe this is where we actually use the idea of a server "Endpoint" which can be summoned from the client? ...except that for clarity, the function should probably be OServer() (not OEndpoint(), as I started to call it earlier -- which referred to a different thing anyway).
At this point, there's some interaction with the Object Registry which needs to be taken into consideration. When we want to initiate contact with a database, we first look it up in the ObjReg using its slug. This (currently) returns the DB Connection object which has been registered -- so either that object needs to know its client-side endpoint (so the client can talk to that), or we need to register that endpoint instead -- possibly as part of the Oper object?
(much later that day...)
So... instead of having the involved functional objects register themselves (via AnObject::WithSlug()), how about having slug-summoned connector-objects? (Am I just reinventing MVC again?)