18 Nov
2021
18 Nov
'21
7 p.m.
On Nov 18, 2021, at 11:49 AM, Dave McGuire <mcguire
at neurotica.com> wrote:
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.
That makes a lot of sense, in retrospect. And making it work that way may not be too
terribly hard.
I already have a machine-readable and semi-human-readable data store for the mapper, a
file in JSON format. I've come to like JSON for this sort of thing. (It's
already used in some API stuff.)
So that's a possible answer. A file like that as the "permanent database",
initialized (a) from a config file in the current format and (b) from other places. A
typical PyDECnet startup would just give the permanent file.
Let me think about this.
paul
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.