hgm wrote:There are many programs that do store their settings (hash size, but sometimes even piece values and eval parameters) on .ini files that they read themselves. I don't think it would be a totally crazy idea if such engines could also write these .ini files themselves, when some of the parameters have been changes through the interface. But it is upto the engines to provide this service, and to decide to which parameters it extends.
I think the engine's own .ini files are not relevant here since there is no doubt that no other instance than an engine itself knows exactly about the intended contents, format and possibly consistency rules of its own .ini file, if there is one. So if there were really a situation where *that* engine.ini file should be updated somehow (I doubt there will in most cases) then only the engine could do that job. *BUT* these engine.ini files are most probably not meant here.
"Saving engine settings between two invocations" in this context I would understand as either updating the engine specific part of winboard.ini, or (when PolyGlot is used) polyglot.ini.
Regarding tournament managers and their role, I propose not to expect the existence and/or proper setup of a TM when designing changes to the WB protocol and/or WinBoard implementation. A TM is a really nice application but it is on top of both the WinBoard GUI and any engines, and we should in general not expect it is there when we are "on the WB level".
The latter means that for me it is not an option to say that "the TM" should care about storing any engine-specific settings. If we only want to express that neither the engine, nor WinBoard, nor an adapter like PolyGlot shall be responsible for storing engine-specific settings then I would prefer to say "the user" in this case, instead of "the TM", where "the user" could of course let a TM do this work for him.
Sven