Today's plan:
Finish up the bare-bones Roto engine, write a progress report, send an RfP.
Discussion
Today's plan:
Finish up the bare-bones Roto engine, write a progress report, send an RfP.
Okay, the config conversion tool is in a reasonable shape, roto engine can run a self-test. Lets have lunch, and write a progress report!
Progress report's draft is done, and I have an hour or two maybe, to squeeze one more thing in, maybe.
Poop. Running into Roto limitations.
Ah, no, it was PEBKAC, but there's a bad Roto compile fail case I will report later.
Anyhow, time's short. New stuff won't make it into the progress report. I don't want to half-ass it.
Will publish the report after bedtime stories, most likely, so in about an hour, hour and a half.
I've been thinking.
In iocaine 4.x, I will not implement per-server initial-seed. I don't think anyone ever used it. I will also change the default seed to be time-based: when iocaine starts up, it'll set the seed based on the current time (chosen so that a new seed would be chosen every 67 hours or so). I might make that configurable too.
In practice, this means that iocaine will choose a time-based seed on startup, and if you restart it within 67 hours, that seed will remain the same. So if you restart it every week or so, it'll have a different seed, and will provide different garbage. That's a change from the iocaine 3 default, where the initial seed was always empty, and thus, the content never changed, unless the seed was also changed.
The syntax will be like:
initial-seed "string"
initial-seed file="/path"
initial-seed from-time="67h"
Another thing I've been pondering about is instance-id. That is used to generate substrings for URL poisoning, and it should not change, ever, but should also be different from every iocaine installation, ideally.
In iocaine 3, this can be set via the config, and if it isn't set, iocaine generates a random string, and saves it in the state file.
iocaine 4 will use the state file more, and I thought: what if this wasn't configurable? Want to change the instance id? Change the state file. Or configure the script to use your own identifiers, rather than auto-generated ones. There's little point in making the instance-id configurable, in my opinion.
Teheheheheeeeeeee.