> And I don't understand why, when going along with the bundle idea, > you are suddenly creating a new configuration file format of your > own. There is a standard format, XML or text based, which can be > easily parsed with OSX APIs (and thus likely *Step APIs as well) as a > dictionary, allowing structured information to be stored and thus > allowing Qemu backends to store their own settings alongside. See > attached one my bundles' configuration.plist file (XML serialized) - > relevant is only the Arguments entry, everything else is GUI > specific. I'm not saying this format (the structure) were perfect but > the underlying "property list" format (key, value-type) is standard > for such bundles, so instead of re-inventing the wheel please take a > look at how it's being done!
I would like to think that having command line options separated by spaces or newlines is a new configuration file format, but it's not. This patch is not meant as a replacement for libvirt or any other backend. It's just a replacement for shell scripts that serve the only purpose of storing command line options. It should be a simple solution for a simple problem. The complex solution for the complex problem is already there and is called libvirt. I don't want to have QEMU parse serialized XML just to replace my '-m 512 -soundhw es1370 -net nic,model=rtl8139' command line. I would simply like to store that command line somewhere. Anyways, it's obvious that this is a delicate issue for many people here. I think the most non-disruptive way of doing this is the '-c' command line option. It doesn't change QEMU default behaviour, it doesn't add new hyphen-less options. I insist on the fact that this should be a simple solution for a simple problem. Cheers, Jorge
