2026/07/03

Friday, July 3, 2026 (#184)

Thursday Friday Saturday

References 2026/06/26 (← links) 2026/06/27 (← links) 2026/06/28 (← links) 2026/06/29 (← links) 2026/06/30 (← links) 2026/07/01 (← links) 2026/07/02 (← links) 2026/07/04 (← links) 2026/07/05 (← links)

Previously:

• 2026/06/26 - last date with notes
• 2026/06/23 - last significant entry

Main Work

• Ferreteria FileSys stuff in order to support sftp in FTM.

I've come to the realization that another part of the file-management class-model needs rethinking. There is a lot of situational context which must be applied when deciding how to handle various requests/calls, and the current model generally handles these poorly or even stands in the way of handling them properly.

• A problem existed where in order to determine the node-type (typically "file" or "folder") to which a Spec is referring, we had to access the Venue object, which was handled by the Ident object -- which required creating the Ident object, which required knowing which Ident podling-class (Fi or Fo) to instantiate, which required already knowing the node-type.
  • This issue has now been fixed by moving Venue out from under Ident, which required simplifying it to no longer store the PSpec (informational functions now require the PSpec as an argument).
• The current (main?) problem is that in some circumstances we need to look at a node to see what type it is, but in other circumstances we may need to create it and therefore cannot expect to get that information from it: the Node must be aware of what type it should be.
  • The first semi-obvious step towards fixing this is that we need to have a way of conveying "file-type to create" in a single variable; this has resulted in the Sys\FileSys\Node\aux\NodeType clade.
  • I'm also thinking that it's a bad idea to have Node-type encoded in the Node's class. It seems better to have the Node capable of "being" any type -- perhaps through sub-objects that can be invoked as needed, e.g. Node->Fil for file operations and Node->Fol for folder operations. Neither of these objects would be classes descended from Node.
  • I need to see how the Fi and Fo variants of Ident actually differ. Q: why do we need them to be related?
    • A: The only substantial difference is in the implementation of the Delete() operation.
      • It may be that there's some value in having that operation be polymorphic, but I'm inclined to think this is either unnecessary or else there's a way of doing it without creating that node-type-knowledge dependency.
  • The Wild podling-classes for Node and Ident were also an attempt to fix this problem; they didn't.

Tentative Conclusions

• Ident's job is to manage the Node's global identity -- the string which uniquely identifies which Node (existing or not) we're looking at, from the perspective of the system on which the code is running, and manages the subsidiary objects which help with managing that string.
  • A lot of the file-information/action functionality that was added to Ident may be just because of native functions which expected a string (PSpec or USpec), rather than a file-handle, as a way of identifying the target node. These more properly belong in Venue, with Ident as a gateway which can automatically supply the PSpec.
• InOut should perhaps not be a single thing but instead separate classes for file and folder I/O (and eventually classes for ops specific to link and devices).
• To consider: should Node objects have a Mode? That could fill the functionality needed in order for a Node to know whether or not it is expected to exist, and what to do if it does or does not...