On Mon, 4 Nov 2013 12:13:59 +0100 Kevin Wolf <kw...@redhat.com> wrote:
> Am 01.11.2013 um 16:12 hat Luiz Capitulino geschrieben: > > On Fri, 01 Nov 2013 08:59:20 -0600 > > Eric Blake <ebl...@redhat.com> wrote: > > > > > 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. > > > > Doing such changes makes me nervous nevertheless. In my mind a stable > > API doesn't change. Of course that there might exceptions, but 99.9% > > of those exceptions should be bug fixes not deliberate API extensions. > > Stable API means that whatever was working before keeps working. Nothing > less, but also nothing more. > > If an extension that changes from error to success is breaking the API, > adding a new QMP command is breaking the API as well. Because sending an > unknown command means returning an error... Let's not turn this into a surreal discussion, I'm sure we all want the best for our users. There's another problem, btw. We're not doing command extensions for input arguments before heaving a way to discover them. Even if there's consensus that extending the command is okay, we need the query-qmp-schema command merged first. IMO, this a blocker requirement (although it shouldn't be difficult to finalize what has been posted already). > > A more compelling argument against it is the quality of the resulting > > command. I'm sure it's going to be anything but a simple, clean API. > > I consider one command with an argument made optional a higher quality > API than having two different commands that do almost the same, except > that the older one has a mandatory argument where the newer one has an > optional argument. I wouldn't expect the new command to be just a duplication of the old one with a new argument. I'm expecting it to have a one-cover all argument or to have a dict or something that makes more sense for the new capabilities. But yes, we need a schema example to see how it would look like.