Optionally truncate displayed arrays when _depth != 0 in text mode

[amitchone]

As it says on the tin, example:

uart:~$ thingset ?HMCU
:85 {"testArray":[1,2,3,4,"..."],"rIpAddr":"192.168.1.1"}
uart:~$ thingset ?HMCU/testArray
:85 [1,2,3,4,5,6,7,8,9,10]

[garethpotter]

May 16-bit systems never die.

[garethpotter]

:85 {"testArray":[1,2,3,4,"..."] }

To me, the ellipsis being in quotes (while syntactically correct JSON) looks very odd.

If this is only for display - and it must be, because it is useless as a transmission format - then it does not matter that it is not correct JSON.

[amitchone]

:85 {"testArray":[1,2,3,4,"..."] }

To me, the ellipsis being in quotes (while syntactically correct JSON) looks very odd.

If this is only for display - and it must be, because it is useless as a transmission format - then it does not matter that it is not correct JSON.

Yes... I was torn between being syntactially valid and the aesthetic... But you raise a good point, there is no genuine use case where it needs to be valid JSON so I will remove the quotes

[amitchone]

Feels a lot better, actually...

uart:~$ thingset ?HMCU
:85 {"testArray":[1,2,3,4,...],"rIpAddr":"192.168.1.1"}
uart:~$ thingset ?HMCU/testArray
:85 [1,2,3,4,5,6,7,8,9,10]
uart:~$ 

[garethpotter]

I would also remove the Oxford comma before the ellipsis.

[garethpotter]

But I can see an argument for not removing it.

[amitchone]

I have no preference either way to be honest... It's trivial to remove

[amitchone]

uart:~$ thingset ?HMCU
:85 {"testArray":[1,2,3,4...],"rIpAddr":"192.168.1.1"}

versus

uart:~$ thingset ?HMCU
:85 {"testArray":[1,2,3,4,...],"rIpAddr":"192.168.1.1"}

[amitchone]

@garethpotter the prevailing (read two additional) opinion is keep the comma

[garethpotter]

@garethpotter the prevailing (read two additional) opinion is keep the comma

To be expected from a bunch of people in Oxford really.

[garethpotter]

As noted in my comments, I think this will have to be a runtime option, because a server cannot return truncated arrays to a network client.

[garethpotter]

To actually engage with the substance of this, the slight issue I have with this is that it leaks what is a distinctly text-only concern, and a subset of a text-only concern at that (i.e. rendering for display) into the base class. Maybe this is fine, but I can't help wondering if there is another way.

[garethpotter]

Responding to myself, the argument in favour of the current implementation is that encodeListSeparator and encodeKeyValuePairSeparator are both already in the base class and are no-ops in binary mode.

[garethpotter]

I don't think this can be a compile-time option. The serial renderer might want to truncate but if a client connects over the network and queries the system in text mode (as is its right), it should expect to get the full data back.

[garethpotter]

This method body should be in the .cpp file.

[garethpotter]

As above.

[garethpotter]

Just as we have ThingSetBinaryDecoderOptions, perhaps we want:

enum ThingSetTextEncoderOptions
{
    abbreviateArrays = 1 << 0
};

[amitchone]

Closed in favour of #62