On 07/14/2017 12:12 PM, Markus Armbruster wrote: > > Instead of the last part, I prefer either > > * so we add a *new* value, such as JSON null.
I like that idea. > > 1. Stop abusing values the schema accepts, but are invalid to mean "do > something else entirely". > > 2. Add a first class null type to QAPI. > > 3. Turn MigrationParameters members tls-creds and tls-hostname into > alternate of str and null. Deprecate "". > > 4. Add a null member to alternate BlockdefRef. Deprecate "". Back-compat concerns: would we still accept "" in place of null for a release or two? Is it time to figure out how to add deprecation notices/events to QMP? Or would this be a clean break-over point (since introspection exists), where if introspection shows there is an alternate between string and null, then libvirt MUST use null instead of "" to get the desired semantics? > > I got patches for 2., and I intend to work on 3. and 4. > > Since this is "only" about "less than general and ugly", we may decide > to leave things as they are if my patches turn out even uglier. > > Meanwhile, opinions? Not much time left for soft freeze (which kind of echoes the dilemma we had at 2.9). Is this something you are aiming for in 2.10, or will it be all the harder to worry about back-compat (because we'll have two releases rather than one before we introduce the alternate-with-null semantics)? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
