You cannot post messages because only members can post, and you are not currently a member.
Description:
This is a mailing list and forum for anyone interested in JSON-RPC.
|
|
|
Maintainers
|
| |
Hi. Could anybody know who is currently maintain this JSON-RPC project?
|
|
|
JSON-RPC 2.0 parameters: scalars only, no arrays + objects?
|
| |
Hi all, I've been using JSON-RPC 2.0 for over six months now, but still have got questions :) I'm working on JSONRPC2LDAP, a web service for giving AJAX browser apps access to LDAP directories via JSON-RPC 2.0. The nature of LDAP requires me to implement a number of methods where I need to pass arrays/composite objects to a number of methods. It looks like the... more »
|
|
|
Request for clarification about named and positional parameters
|
| |
In the draft specification, it says: "The position and name of a parameter is defined by the formal argument list of the procedure." I'm not sure how to read this, since the spec is silent on what is a formal argument list. Indeed, absent a notion of introspection, there really is no such thing as a formal argument list for a procedure,... more »
|
|
|
Another question of clarification
|
| |
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... more »
|
|
|
Request for clarification on response with no ID field
|
| |
In the draft specification, it is written: "id The same id as in the Request it is responding to. If there was an error before detecting the id in the Request (e.g. Parse error/Invalid Request), it MUST be Null." Would it be possible to add some explanation for this? It's hard to guess what the client should do with such an error message, in the... more »
|
|
|
Batch/multicall in JSON-RPC 2.0
|
| |
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... more »
|
|
|
newbie here...
|
| |
hello my name ardissa i want to developing web service base on json rpc protocol.. but i'm newbie in json rpc,,, can you help me, what should i do first.. to develop my web service... if you have more tutorial about json rpc, can you share it with me... thanks before
|
|
|
JSON-RPC used for RPC-style communication with HTML5 Web Workers
|
| |
Hi all, This is actually an update of my previous post to this group [1] regarding pmrpc [2] - an HTML5 JavaScript library for RPC-style inter- window communication. The news is that pmrpc now supports Web Workers [4] - the same API is used to register and call remote procedures for both windows/iframes and workers. The underlying communication... more »
|
|
|
propose definition for a "not implemented" error status
|
| |
Can we define an error code for the situation where a method might not
be implemented ?
Perhaps, referring to section 5.1, something new like
code= -32604
message= Not Implemented
meaning= The method has not been implemented at this time.
(http code=501)
according toRFC 2626 [1], the HTTP status code "501" is well suited... more »
|
|
|
propose adding a "service" property to the request object.
|
| |
In section 4 of the 1.2 proposal where the properties of the request
are identified,
The Request 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".
*[new]*
service A string containing the service name for which the method... more »
|
|
|
|
