2026/03/17
|
Tuesday, March 17, 2026 (#76)
|
|
References |
- 10:03 The question now is where to put that I/O-loop code so that it can be accessed when needed.
- For now, I've called it
DoInOutLoop()and put it in[WFe]IO\Aspect\Connx\Server. It requires theRunnerobject as its only parameter.
- For now, I've called it
- 16:50 That didn't work out because there's no designed path from the endpoint Client to the endpoint Server. I put it into Runner, and added a
QORunner()method toCommand-- so now the endpoint-Client caller can access it via$oCmd->QORunner()->GetIt()->DoInOutLoop(). - 21:00 ...and now the problem is that the loop won't work after the process is closed (because it needs to be able to tell if it's still running, which at that point it is of course not doing), which it does before exiting
DoCommand()-- so we're back to needing a way to signal "stay open on exit".
A metafile-package which is basically {the original file} + {meta-data in an .sqlite database} packaged together in a .tar.gz (or maybe just a .tar, if neither one compresses well). (If the file's contents are small enough to fit efficiently in an .sqlite field, maybe just put the data there instead of having it separately. ...or if there's some way to break the file down into parts, then store each of those parts as fields, from which the original binary-identical file can be reconstructed at need, as in FFS's "File Format Agnosticism".)
Advantage: the file and its meta-data will always be together.
This would work best if there was some way to set up the original filespec as a trigger which would provide the original file contents and/or update the package whenever accessed.