Re: [Json] Limitations on number size?

[Tatu Saloranta <[e-mail]>]

On Wed, Jul 10, 2013 at 2:32 PM, Jacob Davies <[e-mail]> wrote:

> On Tue, Jul 9, 2013 at 7:42 PM, John Cowan <[e-mail]> wrote:
> > Apparently, there are already practical problems with interchanging
> > 64-bit longs: google for [json large numbers bugs] for lots of reports.
>
> The canonical one was Twitter IDs, where they had to introduce a
> (string) field in their JSON APIs called "id_str" which is not
> guaranteed to be equal to the obsolete-but-included (number) field
> "id".
>
> > While there are apparently int32-only systems out there, it's clearly
> > understood that they are unusually restricted: such is not the case
> > for JavaScript-hosted implementations.
>
> Yes, this is why I think the specification itself should note that for
> interoperability with Javascript, the Javascript size limitations must
> be respected, even if the specification does not require that in
> itself. The number of JSON-to-Javascript implementations or uses must
> surely outnumber all other uses of JSON by several orders of magnitude
> so I'd argue that as far as "running code" goes the limitation on
>

Any data to back that up? I would not assume this -- JSON is being used a
lot for service-to-service integration, as well as by native mobile clients.
Javascript as client is certainly important, but I would not assume any
particular majority (even simple one), and certainly not an order of
magnitude.

My experience wrt problem reports differs from that of John's, in that
while feature requests have been filed to allow limitation or truncation,
these have not been highly voted or actively followed. User community also
has not brought this up as a significant issue either.
I suspect this is because it is relatively easy to work around the problem
if and when it occurs. Developers are surprisingly resourceful in solving
problems.

practical, interoperable number size is quite real and surprising to
> people trying to send data to Javascript from non-JS environments
> where larger numbers are available. (I went so far in the Java
> libraries I wrote as to encode/decode longs & Big* as strings.)
>

Mentioning limitations is reasonable, and Javascript can be used as a
common example. There is nothing wrong in outlining challenges, best
practices. But I don't like fearmongering.

Javascript's limited support for numbers is not a JSON-specific problem --
same goes for all data formats as well; for example, XML. This is why some
concerns wrt JSON seem overblown to me.

-+ Tatu +-