[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A brief look at deprecating our JSON extensions over RFC 8259

From: Daniel P . Berrangé
Subject: Re: A brief look at deprecating our JSON extensions over RFC 8259
Date: Mon, 22 Feb 2021 18:01:52 +0000
User-agent: Mutt/2.0.5 (2021-01-21)

On Mon, Feb 22, 2021 at 06:42:00PM +0100, Paolo Bonzini wrote:
> On 22/02/21 15:57, Markus Armbruster wrote:
> > * The block layer's pseudo-protocol "json:" (which can get embedded in
> >    image headers)
> If it gets embedded in image headers, I don't think we'll be able to
> deprecate it ever.  We'd need to keep a converter for old images, at which
> point it's simpler to keep the extensions.

Even if we can only use a standard JSON parser for QMP + QGA, that's a
already a significant net win long term IMHO. Both of those are security
critical components and also areas where we might want different language
impls as we increasingly use a multi-process model, so avoiding use of
extensins is good.

Even for the block layer, we don't neccessarily need to keep compat at
runtime. It could be sufficient to have an extended deprecation period
and then provide an offline helper script to re-write the qcow2 backing
store field to use " instead of ' ....assuming we actually get real
world pushback from people who really have used ' - we don't know if
there are such people yet.

We can do deprecation in a multi stage process - deprecation for everything,
then block it for QMP + QGA after 2 cycles, while still allowing it for qcow2,
and  eventually block for qcow2 3 years later or something like that.

IOW, I wouldn't give up on trying to deprecate it.

|: 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 :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]