Measure of a mindset and end-to-end checks
David Wang : Does Virtual Server support multiple Floppy and CDROM drives? Actually, I do not see why you hope to be able to attach ISO via INI/VMC files and see that as "not programming"... because modifying INI/VMC files require "programming" to do the search/modification, no matter the tool that you use. And between that choice and a commandline tool that can use the Virtual Server Administration API to manipulate VirtualMachine state, I see modification of INI/VMC file to be a fragile, *nix "parse and pray" sort of approach. Sorry... but I do not miss it one bit. ;-)
The above in response to a query about configuring MS Virtual Server "without programming" using INI files or the like. David is right about the first point, but wrong about the second - for pretty much the same reason. Also there is a minor epiphany waiting for him.
The starting point is one of Butler Lampson's observations I read from the original publication of Hints for Computer System Design which can be paraphrased as:
Only end-to-end checks matter - everything else is (or should be) an optimization.
The end-to-end check in this case is loading your virtual machine to see if it really does what you want. If calling an API to modify the configuration file catches some bogus changes - great, that might be an optimization. In the end you still have to load the VM to see that it does indeed do what you want. Editing a text configuration file - in the end - is not a lot different.
As an amusing aside note that quite a lot of the Windows APIs are in the same sense "call-and-pray". Quite a number of Windows APIs take a raft of parameters, and you often cannot tell which combinations of options are meaningful, which are buggy, and which do something quite different from what you expect. So you code the call and test to see if it really does what you expect from the documentation. When it doesn't you look for examples of calling the API that are known to work.
Note a bit of symmetry?
In this particular case - in the end - you will want the configuration in text. Maybe the application reads the text file directly, or maybe you use a utility to dump/load the binary configuration data as text. In either case you will in the end find the text form far more useful. Maybe you offer an API to modify the configuration - I often do this in addition to allowing direct editing of a text configuration file. One epiphany comes when you realize that a text form of the data proves much more useful than you might initially expect.
I have been down this path more than once - from "binary is fine", to "we have one case for a text form", and finally to "oh! there are a bunch of things easier with the text form...". When Lampson was originally writing about end-to-end checks he was talking about networks. In the end you realise the the same notion applies well to software design.