Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1491 closed Bug (fixed)

json floats decimal separator depends on language settings

Reported by: markus Owned by: charles
Priority: Normal Milestone: 1.41
Component: libtransmission Version: 1.40
Severity: Normal Keywords:
Cc:

Description

The representation of floating point numbers in json-rpc responses depends on the language settings used.

From http://trac.transmissionbt.com/browser/trunk/doc/rpc-spec.txt#L14 it says that:

"Floating-point numbers are represented as strings.".

If floats necessarily must be represented as strings instead of native json floating point numbers, they should at least do so in an unambiguous way.


These are responses to json-rpc queries using a swedish(decimal comma) and an american(decimal point) session in Ubuntu 8.10:

Swedish session:

{
    "arguments": {
        "torrents": [
            {
                ...
                "uploadRatio": "5,403589",
                ...
            },
...

American session:

{
    "arguments": {
        "torrents": [
            {
                ...
                "uploadRatio": "5.863311",
                ...
            },
...

"..." is deleted sections.

Change History (6)

comment:1 Changed 13 years ago by charles

Markus: Since the JSON parser is an upstream product, you need to report this bug upstream to its author, Jean Gressmann (jean@…).

When the upstream version is updated, I'll include the update in Transmission.

comment:2 Changed 13 years ago by duncanbeevers

I understand that Transmission's JSON responses are supposed to map well to benc's anemic set of data types, but since there is no floating-point type in benc, why do we need to represent floating points as strings in the RPC protocol? Wouldn't it be simpler and more standard-ish to just use the perfectly-valid JSON floating-point representation?

I haven't examined the behavior of the upstream library in regards to floating-point encoding, but since the JSON spec is unambiguous in this regard, and representation of floating-points as strings is probably what's causing this ambiguity, I move we simply scrap the string encoding of floating-points.

comment:3 Changed 13 years ago by charles

  • Milestone changed from None Set to 1.41
  • Status changed from new to assigned

I think I misread the original ticket description. This isn't a problem with the upstream JSON parser, but a bug in Transmission.

comment:4 Changed 13 years ago by charles

duncanbeevers: I don't have a problem with that suggestion, but in order to do it you'll need to augment the tr_benc "class" to handle floating point numbers. If you want to do that, adding booleans at the same time would probably be a good idea.

comment:5 Changed 13 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

duncanbeevers: I think your idea is a good one, but it's not going to happen in a bugfix release, and this fix needs to be in 1.41. I'm marking this ticket as closed, but feel free to open an enhancement ticket to add floating-point and boolean types to our bencode class...

1.4x: r7165 trunk: r7166

comment:6 Changed 13 years ago by charles

To expand on my previous comment a little more: those svn revisions are kind of a hack, since it forces in benc a "." decimal point regardless of the user's locale. This shouldn't be the case everywhere, only we're encoding it to JSON.

Adding builtin support for real numbers would be a good way of deferring the locale decision until we're actually doing the JSON encoding.

Note: See TracTickets for help on using tickets.