Re: [Qemu-block] qapi: Stop abusing "special" values for something entirely different

[Eric Blake]

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