Eric Blake <ebl...@redhat.com> 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.
