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.
Regar
We've discussed possible solutions. Is anyone working or intending to
work on patches?
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 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, 201
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 Armbru
* 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 origin
* 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 re
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.
>> >
>> > ex
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 inde
* 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 probl
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 problem is around representing 64-bit integers, whether
signed or uns
17 matches
Mail list logo