Just a sample of the Echomail archive
[ << oldest | < older | list | newer > | newest >> ]
|  Message 53  |
|  mark lewis to Wilfred van Velzen  |
|  My GECHO Pro 120 key  |
|  24 Oct 16 08:17:38  |
 24 Oct 16 12:52, you wrote to me: WV>>> Well it's better than the current 9999. And as the config file WV>>> stores it as a 16 bits value, that's all I can do without making WV>>> things complicated... ;) ml>> it isn't that complicated to increase it to a 32bit or possibly a ml>> 64bit number... then when the new release comes out and setup is run, ml>> setup can easily detect that the config file is from an older version ml>> and update it to the new format... WV> That's what I meant with "making things complicated". This little WV> change isn't worth the trouble, of creating an updated config file and WV> all the hassle that it involves... that's not complicated in the least... the setup program loads the bytes of the config file that contain the version... if it is an old version, it loads the old config into the new config making the needed var type changes... once that's done and the operator looks over all the settings to be sure they are correct, then we save the config and we're done... nothing to it... remoteaccess was doing this back in 1990 with at least v0.04... we always had to run setup and exit and then run it again... the conversion of the config file was done during the first run but you had to exit and then run it again... i've used that same method for some of my own tools except that i don't require the exit and restart... it isn't that hard or complicated... FD and FE also did the same type of conversion when their config file formats were updated... ml>> the config file does have a format version number in it for this type ml>> of detection and updating, doesn't it?? WV> Yes it does. excellent... i was pretty sure it did... there's no other reason to have this other than automatically upgrading the config file format... ml>> ok then... you know why to pack and now you know why to /not/ ml>> renumber... WV> ... If your system/software needs it. ;) renumbering should /never ever ever ever/ be forced except in the single extreme circumstance of message base breakage due to overpopulation... it should always be the operator's choice... just like purging and packing are not forced... )\/(ark Always Mount a Scratch Monkey Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong... ... You need to be at least 10% smarter than the equipment. --- * Origin: (1:3634/12.73) |
[ << oldest | < older | list | newer > | newest >> ]