2026/07/17

Friday, July 17, 2026 (#198)

Thursday Friday Saturday

References 2026/07/16 (← links) 2026/07/18 (← links) 2026/07/19 (← links)

Main Work

Ferreteria FileSys stuff in order to support sftp in FTM

Continuing from yesterday's restructuring-thots, I note that both $OHost and $OCred can be NULL -- which means we could just not set them, and the caller could detect that and not use them.

Possibly the Entry API could provide methods for building spec-strings in the formats that seems to be commonly used, reducing the amount of redundant string-building code/logic needed.

If that's going to be the solution, though, then I think that means we'll need a Server class for local files...? ...which feels like something that should already have been addressed by the Venue clade-family...

Some structural notes:

• Venue only knows the protocol (currently: local or SFTP), not the file's identity. Filespec must be provided for any file-operations.
• Ident knows the identity.
• Entry knows where the target filesystem is ($OHost: address/domain + port) and how to gain access ($OCred: any necessary credentials).
• A Stream is not necessarily a file or necessarily remote; it can be one (local file) or the other (remote process), both (remote file), or neither (local process).
  • File descends from Stream, but via Native -- which means we can't make it an abstract parent for both a native-PHP implementation and a #phpseclib implementation without some reorganization.
• Server manages a connection to a system.
  • This seems to be basically just an Entry. Maybe they should be merged? Or should Entry do more of the lifting, and have podlings?
    • Note that USpec is podling of Entry.
  • Server's only podling-class is SSH2, which is a wrapper (can use either Native or SecLib as its Core for operations).
  • I think it would make sense to add Local as another podling-class.
  • Note the Local and Remote folder-classes in Futilities. These are part of the system which does sftp entirely by mounting remote folders with sshfs, which should probably be folded into Ferreteria since it does work, even if it's not going to be used much. (It might still be useful as, say, part of a Network Neighborhood workalike service.)
  • ...and of course this would be parallel to the Local and SSH2 Venue-podlings. Should it even be separate?
    • Probably yes, because this is at the level of SSH2 (not SFTP): it can run processes as well as access files. So, tentatively, Server is for processes and Venue is for filesystem.
    • But wait! It turns out that Server is a podling of Entry (although its sibling, Client, is not). This was a different Server, it turns out: Sys\Data\Engine\endpt\Server
    • Entry has no other podlings. There seem to be several points in favor of merging Server up into Entry.