[HECnet] PyDECnet setup

[Dave McGuire]

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.

                -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA