Re: [Qemu-devel] qapi: Stop abusing "special" values for something entirely different
Eric Blake writes: > 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? Yes. > Is it time to figure out how to add deprecation > notices/events to QMP? Yes, getting that in the next development cycle would be nice. > 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? Feels unnecessarily harsh to me. >> 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)? Let's try to get it into 2.10.
Re: [Qemu-devel] qapi: Stop abusing "special" values for something entirely different
On Fri, Jul 14, 2017 at 07:12:52PM +0200, Markus Armbruster wrote: > Here's what I propose to do: > > 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 "". > > 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? That sounds ok in principle to me, so worth at least proposing the patches so we can see how it works out in practice. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [Qemu-devel] qapi: Stop abusing "special" values for something entirely different
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
