18 Nov
2021
18 Nov
'21
5:49 p.m.
On 11/18/21 9:58 AM, Paul Koning wrote:
Paul, I think the last thing you need here is yet more suggestions on
how to architect the innards of that package, but..
What I would do here is have an internal configuration data structure
which stores all active configuration and can be modified by different
things. One such thing would be a configuration file parser for startup
time use, another might be NICE messages, etc. Then serialize and store
that active configuration in a non-human-readable file.
Optionally, you can recreate the human-readable file (handling any
user-typed comments would be left as a significant exercise for the
reader ;)) instead of storing the serialized data.
But the overarching idea is to add an abstraction layer around the
internal configuration structure and define a small API to access it
from elsewhere in the program.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
I think
that's his point though. Having it exit is going to have non-consistent behavior
depending on how it's setup.
Good point.
I'm thinking about whether running all the shutdown code, then cycling back to the
startup point, will in fact be a valid implementation of "reload". If yes that
would be fairly easy to do. In proper Unix fashion it could be triggered by a SIGHUP
signal (as well as by some API request).
On the node names bit, if people use the syntax "node @nodenames.dat" in the
config, where nodenames.dat is the one in the pydecnet samples directory or equivalent, I
could imagine a "copy known nodes" feature that (a) updates the in-memory state
and (b) writes a new nodenames.dat with that information.
A more general "rewrite the config file to reflect volatile changes" would
likely be more difficult, but that particular one seems doable.