Batch/multicall in JSON-RPC 2.0

[Robert Goldman]

Is there any opportunity to make batch/multicall into an optional
extension?

From my POV it seems like it adds a fair amount of hair to
implementing the protocol:

* now you have to track the set of transactions and probably abort
them all on the first error
* if all the method invocations are successful, you must marshal them
in order
...and so on.

Also, it seems like they introduce oddities from the caller's point of
view. You don't know the order of processing, and if there's an
error, you get only one error response. What if there were multiple
errors? Is there a chance that some of your requests proceed as
zombies after the failure of one? etc., etc.

Would it be possible to provide an explicit query about the
availability of batch/multicall, and make it optional for servers to
implement it (as long as they did implement the rpcBatchAvailable
method)?

Best,
R

[Matt (MPCM)]

I think you are making some assumption that make handling batch more
complicated. The only time the server should return a single error
object is if it cannot decode the incoming json to be an array. If any
of the items in the array trigger an error, it would be one response
object per item in the array that requires a response (non-
notifications).

Batch does not imply transactions so you cannot abort them. They are
not sequential, so they can be marshaled in any order, or in
parallel... that is up to the server.

--
Matt (MPCM)

[Lorenzo Pastrana]

Hi Robert,

A very happy new year to all the list members and

Batching in jsonrpc 2.0 is at this point some kind of 'transport sugar'
with (mostly HTTP) request based protocols in mind just to avoid too
much connections, if you believe you could implement the protocol
without requiring a request ID tracking of some sort you are probably
thinking 'disposable http request' per transaction with p2p result for
request ...

As we're specifying a transport agnostic protocol ID is our only key to
map result to requests not connections, and from this point of view
batching doesn't add a single hair...

BTW, we recently agreed on no execution nor return order and a result
per request unless a fatal error occurs.

Tell me if I over-read you.

Lo.

> --
>
> You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
> 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.
>
>

[Robert Goldman]

On 1/2/10 Jan 2 -5:32 PM, Matt (MPCM) wrote:
> I think you are making some assumption that make handling batch more
> complicated. The only time the server should return a single error
> object is if it cannot decode the incoming json to be an array. If any
> of the items in the array trigger an error, it would be one response
> object per item in the array that requires a response (non-
> notifications).

Thanks, I get it now. I didn't really follow the phrase "if the
multicall itself fails," in "If the multicall itself fails, the reply is
a single error-Response."

Best,
R

[Robert Goldman]

On 1/2/10 Jan 2 -5:32 PM, Lorenzo Pastrana wrote:
> Hi Robert,
>
> A very happy new year to all the list members and
>
> Batching in jsonrpc 2.0 is at this point some kind of 'transport sugar'
> with (mostly HTTP) request based protocols in mind just to avoid too
> much connections, if you believe you could implement the protocol
> without requiring a request ID tracking of some sort you are probably
> thinking 'disposable http request' per transaction with p2p result for
> request ...
>
> As we're specifying a transport agnostic protocol ID is our only key to
> map result to requests not connections, and from this point of view
> batching doesn't add a single hair...
>
> BTW, we recently agreed on no execution nor return order and a result
> per request unless a fatal error occurs.

Ah. Great. This does directly contradict the existing draft, though,
right? It still says:

"The response is an Array of Responses, in the same order as the
Requests ..."

So this should be revised to something like:

"The response is an Array of Responses, which may appear in any order;
they do not have to be sorted to appear in the same order as the array
of requests. Note that any notifications in the procedure call arrays
will not have any response."

Correct?

This still suggests that the responses /must/ be batched together and
that no response can be issued until all have been computed. Is this
desirable, or should the server have the freedom to send some responses
earlier?

By the way, the transport-agnostic feature of JSON-RPC is one of my
favorite aspects, and I am working on using JSON-RPC for cross-language
procedure call over sockets.

Best,
R

[Dennis]

If the response is an array of responses, then it is a 'batch'
execution. The reply must wait till the array is filled, per
definition.

That is, unless the responses can say, or code, something like HTTP
Status code 202 -> 'Accepted' is used. There is no such standardized
JSON-RPC code that I know of, and I didn't see one when I looked
(cursorily) @ the XML-RPC succes/error codes.

BTW, are there any success code standards?