On 11/01/2013 08:51 AM, Luiz Capitulino wrote: > On Wed, 30 Oct 2013 13:25:35 -0600 > Eric Blake <ebl...@redhat.com> wrote: > >> On 10/30/2013 07:49 AM, Markus Armbruster wrote: >> >>> >>> The first proposal is to add another parameter, say "id". Users can >>> then refer either to an arbitrary BDS by "id", or (for backward >>> compatibility) to the root BDS by "device". When the code sees >>> "device", it'll look up the BB, then fetch its root BDS. >>> >>> CON: Existing parameter "device" becomes compatibility cruft. >>> >>> PRO: Clean and obvious semantics (in my opinion). >> >> I like this one as well. > > Does this proposal makes "device" optional for existing commands? If it > does then I'm afraid it breaks compatibility because if you don't > specify a device you'll get an error today.
Changing from error to success is not backwards-incompatible. Old applications will ALWAYS supply device (because it used to be mandatory). That is, a management application that was intentionally omitting 'device' and expecting an error is so unlikely to exist that we can consider such a management app as buggy. For more examples of conversion from error to success, consider the 'block-commit' command. As introduced in 1.3, we did not yet have the implementation to commit the current image. But we designed the command with a view to the future (which we are nearly at, by the way, although I don't know if it will make 1.7 or be delayed to 1.8). In fact, we specifically made the 'top' argument mandatory at the time, and documented that if 'top' was the active layer that the command would fail; but with the full intent of removing the error and instead succeeding once we implement full commit; we also discussed the possibility in the 1.3 time-frame that 'top' could be made optional once block-commit could manage the current image. > > Have you considered adding new commands instead? I'm still not convinced we need new commands yet. But again, proposing the QMP schema first will make that clearer. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
