2026/07/19

Sunday, July 19, 2026 (#200)

Saturday Sunday Monday ⇒ next

References 2026/07/18 (← links) 2026/07/21 (← links) 2026/07/22 (← links)

Main Work

Ferreteria FileSys stuff in order to support sftp in FTM

Relevant notes: Saturday, Friday, Thursday

The question now is: which of these calls is wrong, i.e. incorrectly passing the buck? Tentatively, I think the answer is IO\Aspect\Connx\Stream\Native\File->ActualOpen(), which should be calling fopen() (either directly or via the Venue).

The Local variant of Venue used to handle this (via FileOpen()), but I think that may be where the problem started; in any case, FileOpen() wasn't part of the Venue interface and it wasn't implemented in the SFTP variant.

Further questions:

• Q: Why aren't all the operations specific to accessing an open node in a Stream class instead of in a Venue class?
• Q: Why is Server a thing? ...or should the Native Stream-clade-family be under a Local namespace, if only for organizational clarity?

I'm thinking that maybe what is needed is some clarity around {operations that just need a filespec} (e.g. existence, timestamps) versus {operations on an opened filesys-node} (read/write/position). ...and then there are things which also do I/O, like an opened filesys-node, but are not filesystem entities (most obvious: memory-buffers).

Tentative rules:

• Anything for which a Venue needs a filespec should be delegated to a Node object that retains the spec -- for which I guess we've been using Ident. (Time to rename that? Or is it clear enough, and I just keep forgetting?)
  • One thing about Ident, though, is that it manages/represents the full URL and contains the Venue, so it would be a scope-conflict to have a Venue spawning an Ident object. Maybe we want a class that represents "filespec within current Venue"? ...which kinda describes PSpec... but that's just for managing the local filespec, not for doing operations which may be Venue-dependent...
    • Would it make sense to have PSpec variants for each Venue?
      • ...or perhaps PSpec is basically a "Venue-relative Ident"... but do we want name-mangling ops and node-access ops in the same class, ever? I kinda think not; better would be to have a separate clade-family which has a PSpec object but handles all the filesystem operations.
• Anything for which an Ident object needs an opened node should be in a Stream object, unless that clashes with other Stream functionality. (If there is a clash, then whatever class we create for it should definitely be related to Stream in some way, since they do have overlapping functionality).
• A thought: Maybe Ident should actually be Venue-relative...?

Just to start with, how about:

• rename Venue to VenProto (venue protocol)
• create VenVNode (venue virtual node, i.e. venue-relative filespec operations)
  • ...or maybe VenType and VenNode?
  • Q: How does this interact with Ident? Does it replace it?
    • A: Ident currently manages:
      • USpec and PSpec objects (created as needed)
      • filespec-dependent ops (currently deferred to Venue object)
  • This implies the existence of VenANode, for interaction with actual nodes (I/O, mainly: Stream-stuff).

Tentative Rules

custodial map acting object-class resulting object-class Ident USpec PSpec Ident VenType Ident VenNode VenType VenNode Fil Fol	generative map holder object managed object Node Ident InOut Venue (static) Venue USpec InOut Fil Fol Venue VenType VenNode

Thinking this through in narrative form, the above may actually be too elaborate. The following seems more appropriate:

Starting from a URL (USpec) string:

• The Node quasiconstructor creates a Node object, which then can create on demand:
  • USpec object (parses USpec string, provides PSpec string)
  • PSpec object (parses PSpec string, provides filepath calculations)
  • VenType object (derived from USpec object's protocol-type)
  • VenNode object (has pointer to VenType, uses PSpec)
• The VenNode object can then create on demand:
  • Fil object
  • Fol object