[HECnet] PyDECnet setup
Paul Koning
paulkoning at comcast.net
Thu Nov 18 10:00:59 PST 2021
> 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:
>>> 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.
>
> 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
More information about the Hecnet-list
mailing list