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. 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. Anyways, let's wait for a concrete proposal to have more concrete feedback.
