Should we make a move?

1.1 spec STILL isn't complete, and is too complex, in my opinion.

An we NEED it finished, to make it enterprise-ready and beat the shit
out of immeasurably ugly SOAP.

Being pragmatic and harsh, I'd propose the following changes:

1. Drop all 1.0 compatibility. No, really. How many people do really
use JSON-RPC 1.0? Specifically, let's forget "id" element.
2. Drop requirements on HTTP headers. It's quite enough for each side
to receive parsable JSON - then we assume transport layer is ok.
3. Differentiate strictly between "GET/POST" request types. They are
NOT completely interchangeable and cause confusion. POST should be the
main method, because it's all about JSON. GET - is alternative way
(maybe even another spec, JSON-RPC-Lite).
4. "params" should be of any type. Int, String and Null should be ok.
Let server decide how to process it.
5. Add optional "auth" parameter to request, of arbitrary type. For
those dudes who don't want to deal with HTTP auth and would like to
use session ID or sumfin else.

We need to move forward. Such a brilliant chance to improve Web
Services world shouldn't be missed.

hi,

> 1.1 spec STILL isn't complete, and is too complex, in my opinion.
did you read http://84.16.237.14/jsonrpc/ ?

>; 4. "params" should be of any type. Int, String and Null should be ok.
> Let server decide how to process it.
hmm, I don't think so. in terms of RPC, what would i.e. a string mean?
that it's the only parameter to a procedure call? I think always using
an array/object is cleaner.

regards,
Roland

On 6/5/07, Mikeal Rogers < mikeal%40osafoundation.org">mikealosafoundation.org&gt; wrote:
&gt;
> I'm in 100% agreement with 1, the spec not being finished a big problem, who
> is responsible for editing the spec? who are the stake holders here and can
> we divide some of the work up? is there any formal process what so ever for
> responding to issues publicly?
>
&gt; I'm in strong disagreement with 2, these headers are absolutely necessary
> for proper interop with REST based services and without them this standard
> will never have a chance at making it through the IETF or a comparable
> standards certification process.
>
I think this should be made optional. I got a project in which I'm
implementing json-rpc over tcp (I have a patched version of
json-rpc.org code with it)

&gt; On point 3, I too think the use of GET should be a separate specification.
> Breaking the current spec in to two different use cases is draining and
> adding a lot of unnecessary complexity.
>
+1
&gt; I don't see the use case for params being any type other than array or
> object?
>
me neither the overhead of sending a json-rpc package is way too much
for just seding int.

> I also don't see the use case for auth in the parameters, auth should be
> handled at the HTTP layer which has all the protocol support necessary. If
> they can't "deal" with HTTP auth (who are these people?), then they can add
> an arbitrary auth parameter to the params list of all the method calls and
> parse it out before dispatching the remote method, this will end up being
&gt; more interoperable than having a base level attribute with no specific
> semantics other than "it might hold auth or session data in some format&quot; and
> we don't want to add a bunch of extra auth semantics to the current spec.
&gt;
> I'd like to add one point, get off of yahoo groups. The formatting of these
&gt; emails make responses difficult when the html bodies barely parse. Not to
> mention the annoying ads that are added to each email. My participation has
> been lessened by the fact that using yahoo groups is painful. I can suggest
> various alternatives and may even be able to get IT here at the Open Source
&gt; Applications Foundation to set up a mailman account for the json-rpc
> community, we already host an IETF working group and some other open
>; standards/projects group lists that aren't directly funded by OSAF.
&gt;
yes pleeease googlegroups are good I suggest we move overthere.
> -Mikeal
>
> On Jun 1, 2007, at 5:22 AM, konstantin_yegupov wrote:
&gt;
>
>
&gt; 1.1 spec STILL isn't complete, and is too complex, in my opinion.
>
>; An we NEED it finished, to make it enterprise-ready and beat the shit
>; out of immeasurably ugly SOAP.
&gt;
> Being pragmatic and harsh, I'd propose the following changes:
>
>; 1. Drop all 1.0 compatibility. No, really. How many people do really
&gt; use JSON-RPC 1.0? Specifically, let's forget "id&quot; element.
>
>
>
>
>
&gt;
> 2. Drop requirements on HTTP headers. It's quite enough for each side
>; to receive parsable JSON - then we assume transport layer is ok.
> 3. Differentiate strictly between "GET/POST" request types. They are
> NOT completely interchangeable and cause confusion. POST should be the
> main method, because it's all about JSON. GET - is alternative way
> (maybe even another spec, JSON-RPC-Lite).
&gt; 4. "params" should be of any type. Int, String and Null should be ok.
> Let server decide how to process it.
> 5. Add optional "auth" parameter to request, of arbitrary type. For
> those dudes who don't want to deal with HTTP auth and would like to
> use session ID or sumfin else.
&gt;
> We need to move forward. Such a brilliant chance to improve Web
> Services world shouldn't be missed.
>
>
>
&gt;
>
>
&gt;