Position of the id value in the response object

[mar]

I wonder why the id is at least position of the response. I think, it should be before the result value.

Reason: When a client calls many methods at once (e.g. within one Http request), it has to use the value of the id to "dispatch" the returning results.
When the id value comes after the result value, the client must first read the result in a "generic" way (e.g. in memory hash maps etc.) and then, it can read the id and dispatch the result to the corresponding handler.
Hence, there is no way for the handler to read the result directly from the json stream.

Let's assume that the response object is very large and that the client wants to store the result of a specific call directly to disk (without reading the whole amount of data into memory). How can this be accomplished when the client knows the "destination" of the result only after reading the whole result?

Or let's assume that performance is really an issue on the client (very low memory and slow cpu) and the client wants to create a concrete object data structure directly from the json stream (without the intermediate step over the generic hash maps). How can this be accomplished when the client knows the "type" of the data structure only after reading the whole result?

I hope, you have a good reason for putting the id at the last position. Or is is still possible to put it before the result?

[Matt (MPCM)]

To quote the json.org front page : "An object is an unordered set of name/value pairs. An object begins with { (left brace"

That *unordered set* part means the order is not preserved. You could setup your encorder to weight certain keys over others, but it would require you to control the client and server to ensure this happened.

Conceptually, you should be able to extract the id, but you *still* need to read to the end of the stream enough to determine:

1. It is valid json
2. It is a valid json-rpc response object
3. It contains an id that client issued

I'm a little confused how you plan on checking the above but are still not able to extract the key. Perhaps someone here who deals with json streams and large response objects can offer more suggestions.

--
Matt (MPCM)

[mar]

The JSON-RPC standard uses JSON and adds some constraints. It says e.g.

The Response is expressed as a single JSON Object, with the following members:
- jsonrpc A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0"
...

Hence, all valid JSON-RPC responses are valid JSON Objects, but not all valid JSON Objects are valid JSON-RPC responses.

But then, it is also perfectly legal if the JSON-RPC standard required that the order of the members MUST be the following: jsonrpc, id, result, error.
This is simply another constraint that reduces the set of possible result objects without breaking the JSON standard.
A constraint like this would not reduce the power of JSON-RPC but would simplify the life of many performance-aware developers out there.

To clear up your confusion, I provide another example:

Lets assume that there is a small database on the client with the tables "contacts" and "tasks". And the client wants to populate both tables with an rpc call batch:

--> [
        {"jsonrpc": "2.0", "method": "get_contacts", "params": null, "id": "1"},
        {"jsonrpc": "2.0", "method": "get_tasks", "params": null, "id": "2"}
    ]

If the client can be sure that the order of the members in the response is "jsonrpc, id, result", then it can determine the destination table before reading the result and insert one record after the other into the table while reading the input stream. Hence it uses constant memory, regardless of the size of the response. If the client detects a syntax error after the e.g. 234th entry, it can rollback the transaction and handle the error.

However, if the id might come after the result, the client has to read the whole result into memory and then determine the destination table and write the records down. In this case, the memory usage depends on the size of the response (which is not that nice).

I conclude:

It would be an advantage (for free) if the standard required that the order of the members in the response MUST be "jsonrpc, id, result, error".

For the request, it is important that the member "method" comes before the member "params" (similar considerations).

[Alexandre Morgaut]

I must say that ordered properties  doesn't for free.

As the JSON specification says object properties are unordered, in compliance with ECMAScript from which it was designed, you have no guaranty from JSON librairies to get this order preserved either during parsing or stringification.

Such constraint would then require many implementors to also write a specific JSON lib

From iPhone

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To view this discussion on the web visit https://groups.google.com/d/msg/json-rpc/-/5XYOjeQFTN0J.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

Alexandre Morgaut Wakanda Community Manager Email : Alexandr...@4d.com Web : www.4D.com

4D SAS 60, rue d'Alsace 92110 Clichy - France Standard : +33 1 40 87 92 00

 

[Alexandre Morgaut]

If you really want order, what you should do is something like

Request:

// array with: version, message type, id, method, params

{"jsonrpc":["3.0", "request", 1, "get_tasks", null]}

Response

// array with: version, message type, id, result, error

{"jsonrpc":["3.0", "response", 1, [], null]}

Note that in case of notification there should be no id. It might require to specify that the null value is reserved to represent a notification. 

It still allow group of requests embeded in arrays but beware that JSON arrays are sensible to JSON injection attacks. It'd better be embedded in à JSON object itself.

Ex: 

{"jsonrpc":["3.0","request-stream",[

{"jsonrpc":["3.0", "request", 1, "get_contacts", null]},

{"jsonrpc":["3.0", "request", 1, "get_tasks", null]}

]]}

With such format, it would definitely be another version number to prevent conflict with existing json-rpc implementations, that why I did wrote "3.0"

From iPhone

[Shane Green]

I'm totally confused by this conversation because it seems to imply that a batch invocation would come back with a single ID object, when the server in fact returns an array of individually identified responses which could be dispatched as they were received assuming each one meaning wasn't dependent on full receipt of those that followed, which it shouldn't because those kinds of commands shouldn't be batched in the first place.  Either that, or the question is referring to a single command that returns one object so large that streaming and interleaved dispatching of unordered its unordered name/value pairs is a concern…or am I missing something?

Or perhaps there is a new specification and the array response is going away, which wouldn't make any sensel, especially not without at least supporting both forms, and returning an array of ID'd response in response to a request of ID'd requests.

Shane Green 

www.umbrellacode.com

408-692-4666 | sh...@umbrellacode.com

<8e7127.png>

Alexandre Morgaut Wakanda Community Manager Email : Alexandr...@4d.com Web : www.4D.com

4D SAS 60, rue d'Alsace 92110 Clichy - France Standard : +33 1 40 87 92 00

-- 
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.

[Matt (MPCM)]

I think his goal is to stream the data into a store of some type, then process the data as it is approved, accepted, dispatched, etc...

So, lets say you have a 2GB request object sent to your server, he's looking to know from parsing the steam early on that the request has certain values in order to be processed differently, ahead of the decoding the entire json object.

Having a SAX style json parser that throws these sorts of events would allow this, especially if the stream processing and parsing is segmented from the core json-rpc dispatch process.  This isn't too hard in practice, but will cause non-optimal processing/scheduling if the id / method keys come last.

This seems to be the objection from the original post (?). The solution he proposed was placing additional rules on the order of members within a request object. I also assume that this would also extend to response object for the same reasons.

Not saying I agree this needs 'fixing', just clarifying what the topic seems to be.

[mar]

Thanks, Matt, for this clarification. Your assumptions are correct.