Re: [Json] Limitations on number size?

Is this thread making any progress over the minimal edit I proposed? I
think not, fwiw.

- Rob

On Wed, Jul 10, 2013 at 9:10 PM, Tatu Saloranta <tsaloranta@gmail.com>wrote:

>
>
>
> On Wed, Jul 10, 2013 at 2:32 PM, Jacob Davies <jacob@well.com> wrote:
>
>> On Tue, Jul 9, 2013 at 7:42 PM, John Cowan <cowan@mercury.ccil.org>
>> 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 +-
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>
>