On Tue, Jun 04, 2019 at 08:38:24AM +0200, Markus Armbruster wrote:
> We've discussed possible solutions. Is anyone working or intending to
> work on patches?
I'm not actively working on it now, nor any plans in the near future.
I would like to see it fixed sooner rather than later though.
We've discussed possible solutions. Is anyone working or intending to
work on patches?
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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 writes:
[...]
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 writes:
> > >
> > > > On 5/13/19 8:53 AM, Markus Armbruster wrote:
> > > >
> > > >>>
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, May 14, 2019 at 08:02:49AM +0200, Markus Armbruster wrote:
> > Eric Blake writes:
> >
> > > On 5/13/19 8:53 AM, Markus Armbruster wrote:
> > >
> > >>> We have a few options
> > >>>
> > >>> 1. Use string format for values > 2^53-1, int
On Tue, May 14, 2019 at 08:02:49AM +0200, Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 5/13/19 8:53 AM, Markus Armbruster wrote:
> >
> >>> We have a few options
> >>>
> >>> 1. Use string format for values > 2^53-1, int format below that
> >>> 2. Use string format for all fields which
Eric Blake writes:
> On 5/13/19 8:53 AM, Markus Armbruster wrote:
>
>>> We have a few options
>>>
>>> 1. Use string format for values > 2^53-1, int format below that
>>> 2. Use string format for all fields which are 64-bit ints whether
>>> signed or unsigned
>>> 3. Use string format for
On 5/13/19 8:53 AM, Markus Armbruster wrote:
>> We have a few options
>>
>> 1. Use string format for values > 2^53-1, int format below that
>> 2. Use string format for all fields which are 64-bit ints whether
>> signed or unsigned
>> 3. Use string format for all fields which are integers,
Daniel P. Berrangé writes:
> On Mon, May 13, 2019 at 01:29:34PM +0100, Dr. David Alan Gilbert wrote:
>> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>> > On Wed, May 08, 2019 at 02:44:07PM +0200, Markus Armbruster wrote:
>> > > Daniel P. Berrangé writes:
>> > >
>> > > > On Tue, May 07,
On Mon, May 13, 2019 at 03:53:19PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Wed, May 08, 2019 at 02:44:07PM +0200, Markus Armbruster wrote:
> [...]
> >> Double-checking: do you propose to encode *all* numbers as strings, or
> >> just certain "problematic" numbers?
>
Daniel P. Berrangé writes:
> On Wed, May 08, 2019 at 02:44:07PM +0200, Markus Armbruster wrote:
[...]
>> Double-checking: do you propose to encode *all* numbers as strings, or
>> just certain "problematic" numbers?
>>
>> If the latter, I guess your idea of "problematic" is "not representable
>>
On Mon, May 13, 2019 at 01:29:34PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > On Wed, May 08, 2019 at 02:44:07PM +0200, Markus Armbruster wrote:
> > > Daniel P. Berrangé writes:
> > >
> > > > On Tue, May 07, 2019 at 10:47:06AM +0200, Markus
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, May 08, 2019 at 02:44:07PM +0200, Markus Armbruster wrote:
> > Daniel P. Berrangé writes:
> >
> > > On Tue, May 07, 2019 at 10:47:06AM +0200, Markus Armbruster wrote:
> > >
> > >> >> > I can think of some options:
> > >> >> >
> > >> >>
On Wed, May 08, 2019 at 02:44:07PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Tue, May 07, 2019 at 10:47:06AM +0200, Markus Armbruster wrote:
> >
> >> >> > I can think of some options:
> >> >> >
> >> >> > 1. Encode unsigned 64-bit integers as signed 64-bit integers.
Daniel P. Berrangé writes:
> On Tue, May 07, 2019 at 10:47:06AM +0200, Markus Armbruster wrote:
>
>> > The Golang JSON parser decodes JSON numbers to float64 by default so
>> > will have this precision limitation too, though at least they provide
>> > a backdoor for custom parsing from the
* Markus Armbruster (arm...@redhat.com) wrote:
> Eric Blake writes:
>
> > On 5/7/19 4:39 AM, Daniel P. Berrangé wrote:
> >
> >>> JSON is terrible at interoperability, so good luck with that.
> >>>
> >>> If you reduce your order to "the commonly used JSON libraries we know",
> >>> we can talk.
>
Eric Blake writes:
> On 5/7/19 4:39 AM, Daniel P. Berrangé wrote:
>
>>> JSON is terrible at interoperability, so good luck with that.
>>>
>>> If you reduce your order to "the commonly used JSON libraries we know",
>>> we can talk.
>>
>> I don't particularly want us to rely on semantics of small
On 5/7/19 4:39 AM, Daniel P. Berrangé wrote:
>> JSON is terrible at interoperability, so good luck with that.
>>
>> If you reduce your order to "the commonly used JSON libraries we know",
>> we can talk.
>
> I don't particularly want us to rely on semantics of small known set
> of JSON libs. I
On Tue, May 07, 2019 at 10:47:06AM +0200, Markus Armbruster wrote:
> > The Golang JSON parser decodes JSON numbers to float64 by default so
> > will have this precision limitation too, though at least they provide
> > a backdoor for custom parsing from the original serialized representation.
> >
Daniel P. Berrangé writes:
> On Tue, Apr 30, 2019 at 03:45:46PM +0100, Dr. David Alan Gilbert wrote:
>> * Daniel P. Berrangé (berra...@redhat.com) wrote:
>> > The QEMU QMP service is based on JSON which is nice because that is a
>> > widely supported "standard" data format.
>> >
>> >
On Tue, Apr 30, 2019 at 03:45:46PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > The QEMU QMP service is based on JSON which is nice because that is a
> > widely supported "standard" data format.
> >
> > except QEMU's implementation (and
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> The QEMU QMP service is based on JSON which is nice because that is a
> widely supported "standard" data format.
>
> except QEMU's implementation (and indeed most impls) are not strictly
> standards compliant.
>
> Specifically the
22 matches
Mail list logo
