On Tue, May 14, 2019 at 10:43:31 +0100, Daniel Berrange wrote: > On Tue, May 14, 2019 at 10:37:55AM +0100, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > > On Tue, May 14, 2019 at 08:02:49AM +0200, Markus Armbruster wrote: > > > > Eric Blake <ebl...@redhat.com> writes:
[...] > > > Unless I'm missing something, this should ensure we don't loose precision, > > > can always parse large numbers, and can internally change QEMU precision > > > from int8/16/32 upto full int64 without breaking clients. > > > > But we could be stricter and simpler in string mode: > > > > - QEMU & clients MUST format integer fields as strings, always > > - QEMU & clients MUST parse only strings for integer fields. > > > > That's (3) above, but also meets your requirements. > > Yep, given that we don't actually expose the int8/int16/int32/int64 > distinction via the QMP introspection data, that would be fine too. > > Its basically saying we'll never use JSON's number format. I think this would make the most sense. If you are going to switch to the "string" mode, why bother doing any compat?
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
