Another question of clarification

[Robert Goldman]

In the error messages part of the proposed standard, we read that
error codes -32099..-32000 are reserved for implementation-defined
server errors.

This leaves me wondering --- what are all of the other integers for?
Are all JSON-RPC errors that we define for our own applications to lie
in this range? If so, what is the rest of the integer range for? If
not, what is a JSON-RPC error that is /not/ a server error?

If the spec is supposed to say what is reserved for standardized
errors, then why list -32099..-32000 at all? Why not just say that we
should error numbers > -32000 and leave it at that?

Probably there's a good reason for this, but it doesn't come through
in the proposed spec language.

[Matt (MPCM)]

I believe this was setup originally to map a little closer to the xml-
rpc error codes.

The original json-rpc spec did not suggest what the error object
should consist of, so 2.0 offered a little more structure. I'm a
little fuzzy on the history of the choices around this, but searching
the old messages might clarify it. Perhaps someone else more familiar
with this portion could post?

--
Matt (MPCM)

[Robert Goldman]

Right, but shouldn't we drop from the standard those reserved numbers
that turn out not actually to be reserved (i.e., they are actually for
programmers to use as they like)? It turns the meaning of "reserved"
on its head.

I suggest you just reserve the whole block from -32000 down, and flush
the odd sentence about implementation-defined server errors.

For that matter, one could simplify by reserving all codes from -32000
down, instead of stopping at -32768. I don't think anyone would
really be harmed by losing access to -32769, and it would make the
spec easier to read.

May I suggest that you additionally impose some closed interval on the
value of codes? People implementing JSON-RPC in languages with more
rigid type systems where integers don't just automatically roll over
to bignums may be harmed by leaving this open.

Best,
R

[Matt (MPCM)]

The are "reserved" so that client libraries and api's don't use them
and come to rely on them, and then for some reason the spec revision
needs them as it evolves. It is more that they are reserved for future
use, though I find it unlikely we'll ever fill them.

People using rigid type systems should not have an issue, as this
would be sorted out by the json encoder/decoder. They would just have
to use a sufficient type for the range. Though I appreciate your point
about limiting the size to something more defined.

--
Matt (MPCM)

[Robert Goldman]

On 1/4/10 Jan 4 -8:38 AM, Matt (MPCM) wrote:
> The are "reserved" so that client libraries and api's don't use them
> and come to rely on them, and then for some reason the spec revision
> needs them as it evolves. It is more that they are reserved for future
> use, though I find it unlikely we'll ever fill them.

Right. I'm not objecting to reserving them, I just think that simply
saying "we reserve these," is better than "we reserve these for you to
use," which strikes me as odd! :-)

>
> People using rigid type systems should not have an issue, as this
> would be sorted out by the json encoder/decoder.

I suppose, but this assumes that these people have access to a
pre-existing json encoder/decoder. I wouldn't be surprised if the
people implementing the JSON-RPC server/client would also find
themselves implementing the encoder/decoder at the same time.

Not a big deal, though.

Best,
Robert