[DFD] new operational mode being considered

[Travis]

I've been working on a technical document for dfd_keeper:

http://www.subspacefield.org/security/dfd_keeper/

The way you used to use DFD was that a script would use the dfd_keeper
class to create rules and perhaps some initial variables.  Then it
would implement commands that users could call.

The idea was that your dynamic state was stored in DFD variables,
which could then be persisted across reboots or runs of the script.
Only if the variables used by the class changed would the persistent
state be lost.

But this was a hindrance to me, I did not like the arbitrary
distinction between rules and the variables that rules used.

I also disliked how the user script had to do so much boilerplate to
get things moving.

So now, what I am thinking of is a new way for dfd_keeper to operate
in a new mode.  The user script will use the dfd_keeper class to
generate rules and variables, but will not actually start the main
loop.  What it will do instead is to freeze together all the code to
implement commands, the rules it had defined, and the variables
referenced by the rules into a single frozen image.

Then, they will invoke a new script which simply unfreezes the frozen
state and starts running it.

This eliminates the arbitrary-seeming persistence and makes everything
persist across reboots or re-runs.
-- 
Crypto ergo sum.  http://www.subspacefield.org/~travis/
Truth does not fear scrutiny or competition, only lies do.
If you are a spammer, please email john at subspacefield.org to get blacklisted.