[Web-SIG] [proposal] merging jsonrpc into xmlrpc

[Graham Dumpleton]

2008/4/7 Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de>:
> Hi,
>
>  since json-rpc and xml-rpc basically do the same
>  and the only difference is the content-type (json is more concise),
>  i propose to create a single xml/json-rpc module.
>
>  I did the a semilar proposal to stdlib-sig,
>  they told me to ask in web-sig about the details cause of json.

To repeat something I said on list a while back, this time phrased
properly to correctly refer to JSON-RPC. :-)

The problem with the JSON-RPC 1.0 specification was that it wasn't
always as clear as could have been. As a result different server side
implementations interpreted or implemented it differently, as did the
JavaScript clients. I'll admit that it has been a while since I looked
at it and maybe things have improved, but certainly it used to be the
case that finding a JavaScript library that talked to a specific
server side implementation wasn't always easy. End result was that the
JavaScript library would often only work with the specific web
framework it was originally designed for and nothing else.

The problem areas were, different interpretations of what could be
supplied in an error response. Whether an integer, string or arbitrary
object should be used as the id attribute in a request. Finally, some
JavaScript clients would only work with a server side implementation
which provided introspection methods as they would dynamically create
a JavaScript proxy object based on a call of the introspection
methods.

Unfortunately the JSON-RPC 1.1 draft specification didn't necessarily
make things better. Rather than creating a proper layered
specification which separated lower level transport and encoding
concerns from higher level application concepts such as introspection
they bundle it all together. Thus they try to enforce that a server
must support introspection even though doing so may be totally
impractical depending on what the JSON-RPC  server adapter is hooking
in to. They also introduced all this muck about having to support both
positional and named parameters at the same time. The JSON-RPC 1.1
specification was also never really completed and left out details
such as standard error codes etc that there were proposing be
specified.

Thus my question is, what version of the JSON-RPC specification are
you intending to support? Also what form would the error response take
so that it works with a suitable number of JSON-RPC clients? Are you
prepared to go and test it with a sufficient range of clients to make
sure Python implemented server side interops properly?

Graham