I downloaded and installed json-rpc for Python, ran the simple check
using the ServiceProxy inside a python shell, and it works fine!

But when I copy/paste the example code here

#!/usr/bin/env python
from jsonrpc import handleCGI, ServiceMethod

@ServiceMethod
def echo(msg):
     return msg

if __name__ == "__main__":
     handleCGI()
################## end

I immediately get this error:

Traceback (most recent call last):
   File "foo.py", line 11, in ?
     handleCGI()
   File "/usr/lib/python2.4/site-packages/jsonrpc/cgiwrapper.py", line
45, in handleCGI
     CGIServiceHandler(service).handleRequest(fin, fout, env)
   File "/usr/lib/python2.4/site-packages/jsonrpc/cgiwrapper.py", line
25, in handleRequest
     resultData = ServiceHandler.handleRequest(self, data)
   File "/usr/lib/python2.4/site-packages/jsonrpc/serviceHandler.py",
line 78, in handleRequest
     resultdata = self.translateResult(result, err, id_)
   File "/usr/lib/python2.4/site-packages/jsonrpc/serviceHandler.py",
line 104, in translateResult
     err = {"name": err.__class__.__name__, "message":err.message}
AttributeError: ServiceRequestNotTranslatable instance has no
attribute 'message'

Am I doing something really silly that's causing this?

Thanks!
Paul

> Only json-rpc over HTTP is covered in the new spec.
yes, but I separated HTTP from the spec in http://84.16.237.14/jsonrpc/.

and I and many others think http://84.16.237.14/jsonrpc/ is a major
improvement to the current spec, so I would suggest to further work on
base of this suggestion.

> Nobody is saying you MUST use json-rpc over HTTP, we're just saying
> the spec that is being worked on now is only going to try and cover
> the case of json-rpc over HTTP.
which is really not necessary, see my spec.

regards,
Roland

Hi

I coded this a while ago for a small project I have which should get
it's own server (no need for apache) If I remember correctly it
doesn't depends on anything else, just drop it on your co and add the
import to __init__.py and you got a fully functional jsonhttpserver.
It follows all the conventions of the original package so

usage:

from serviceImpl import TestService
from jsonrpc import handleHTTP

handleHTTP(ChudadiService())

please let me know if this is a good idea to include in the distro so
I can clean it up a bit (for example it needs a port param)

On 6/6/07, Jan-Klaas Kollhof <keyjaque@...> wrote:
>
>
>
>
>
>
> Hey,
>
>  > 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?
>
>  I, Jan-Klaas Kollhof, created the 1.0 specs.
>  Atif has been the driving force behind the 1.1 specs.
>
>  Unfortunately, I have had little time in the past months to
>  participate in the JSON-RPC discussions/specs.
>
>  Any volunteers to help out are more than welcome to do so.
>  I can add accounts for trac and sft on json-rpc.org if needed.
>
I'll like to work on that. I can give a nice maintenance run to the
trac, milestones, versions, we could even install the
http://trac-hacks.org/wiki/AccountManagerPlugin plugin so everyone
that needs an account can get it without admin intervention.

>  > I'd like to add one point, get off of yahoo groups. I can suggest
>  various alternatives and may even be
>  > able to get IT here at the Open Source 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.
>
>  I could install a mailinglist on json-rpc.org or add a forward address
>  to a list hosteted somewhere else.
or get a googlegroup it's email formatting is sane.
>
>  Jan
>
>

On 6/5/07, Mikeal Rogers <mikeal@...> wrote:
>
> 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?
>
> 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)

> 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
> 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
> more interoperable than having a base level attribute with no specific
> semantics other than "it might hold auth or session data in some format" and
> we don't want to add a bunch of extra auth semantics to the current spec.
>
> I'd like to add one point, get off of yahoo groups. The formatting of these
> 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
> 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.
>
yes pleeease googlegroups are good I suggest we move overthere.
> -Mikeal
>
> On Jun 1, 2007, at 5:22 AM, konstantin_yegupov wrote:
>
>
>
> 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 I found this a while ago and it's part of my patch at the message
call "server-to-client message? and a small patch."

although my path covers all of the validation, I believe my solution
is better because it will make sure that the server is sending a
response which is actual json data. As for checking each value in the
dict I think we need to find a better sanity check.


On 6/8/07, jaimewyant <programmer.py@...> wrote:
>
>
>
>
>
>
> Hi all!
>
>  I've found a small bug in the ServiceProxy class (proxy.py).
>
>  The 1.1 draft spec, section 7.3 - Procedure Return Object, states that
>  the error member "MUST be entirely omitted if there was no error."
>
>  The ServiceProxy class unconditionally checks for this member ->
>
>  ...
>  if resp['error'] != None:
>    ...
>
>  This fails if a successful call is made.  I assume the ServiceProxy is
>  written against the 1.1 spec.  It's a simple fix ->
>
>  [jwyant@l-jwyant:jsonrpc]$ svn diff proxy.py
>  Index: proxy.py
>  ===================================================================
>  --- proxy.py    (revision 17)
>  +++ proxy.py    (working copy)
>  @@ -41,9 +41,8 @@
>            postdata = dumps({"method": self.__serviceName, 'params':
>  args, 'id':'
>  jsonrpc'})
>            respdata = urllib.urlopen(self.__serviceURL, postdata).read()
>            resp = loads(respdata)
>  -         if resp['error'] != None:
>  +         if 'error' in resp:
>                raise JSONRPCException(resp['error'])
>            else:
>                return resp['result']
>
>  Also, I just noticed that the ServiceHandler.translateResult method is
>  not 1.1 compliant, because it unconditionally adds the 'error' member
>  to it's returned dictionary.
>
>  Thanks!
>  jw
>
>

Hi all!

I've found a small bug in the ServiceProxy class (proxy.py).

The 1.1 draft spec, section 7.3 - Procedure Return Object, states that
the error member "MUST be entirely omitted if there was no error."

The ServiceProxy class unconditionally checks for this member ->

   ...
if resp['error'] != None:
   ...

This fails if a successful call is made.  I assume the ServiceProxy is
written against the 1.1 spec.  It's a simple fix ->

[jwyant@l-jwyant:jsonrpc]$ svn diff proxy.py
Index: proxy.py
===================================================================
--- proxy.py    (revision 17)
+++ proxy.py    (working copy)
@@ -41,9 +41,8 @@
           postdata = dumps({"method": self.__serviceName, 'params':
args, 'id':'
jsonrpc'})
           respdata = urllib.urlopen(self.__serviceURL, postdata).read()
           resp = loads(respdata)
-         if resp['error'] != None:
+         if 'error' in resp:
               raise JSONRPCException(resp['error'])
           else:
               return resp['result']

Also, I just noticed that the ServiceHandler.translateResult method is
not 1.1 compliant, because it unconditionally adds the 'error' member
to it's returned dictionary.

Thanks!
jw

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

Hi all.

I've found a minor bug when using the modpywrapper.  If you request a
methodthat does not exist, then ModPyServiceHandler raises a
ServiceImplementaionNotFound exception (that's misspelled, btw):

     if not os.path.exists(os.path.join(modulePath, moduleName + ".py")):
         raise ServiceImplementaionNotFound()

This method is called from ServiceHandler, which handles the exception
by translating the error like so:

     def translateResult(self, rslt, err, id_):
         if err != None:
             err = {"name": err.__class__.__name__, "message":err.message}
             rslt = None

Above, err is an instance of ServiceImplementaionNotFound, which does
not have a message property.  So, when the err dictionary is built, or
attempted to be built, you get an AttributeError:

     PythonHandler jsonrpc: AttributeError:
ServiceImplementaionNotFound instance has no attribute 'message'

Anyway, this is how I fixed it locally.  Y'all can fix it however
y'all see fit...

[jwyant@l-jwyant:python-jsonrpc]$ svn diff jsonrpc/modpywrapper.py
Index: jsonrpc/modpywrapper.py
===================================================================
--- jsonrpc/modpywrapper.py     (revision 17)
+++ jsonrpc/modpywrapper.py     (working copy)
@@ -19,7 +19,9 @@
          (moduleName, ext) = os.path.splitext(fileName)

          if not os.path.exists(os.path.join(modulePath, moduleName +
".py")):
-            raise ServiceImplementaionNotFound()
+            e = ServiceImplementaionNotFound()
+            e.message = "Service %s could not be found." % name
+            raise e
          else:
              if not modulePath in sys.path:
                  sys.path.insert(0, modulePath)

Good day!
jw

Hey,

> 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?


I, Jan-Klaas Kollhof, created the 1.0 specs.
Atif has been the driving force behind the 1.1 specs.

Unfortunately, I have had little time in the past months to
participate in the JSON-RPC discussions/specs.

Any volunteers to help out are more than welcome to do so.
I can add accounts for trac and sft on json-rpc.org if needed.


> I'd like to add one point, get off of yahoo groups. I can suggest
various alternatives and may even be
> able to get IT here at the Open Source 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.

I could install a mailinglist on json-rpc.org or add a forward address
to a list hosteted somewhere else.


Jan

Hey,

I did have a quick look at the other mails, just have not put it in
the code yet.

Thanks


--- In json-rpc@yahoogroups.com, "Jorge Vargas" <jorge.vargas@...> wrote:
>
> hi Jan. about trac it's probably the stupid proxy here at my office for
> someone reason noone knows how to configure it "right"..... anyway
where you
> able to see my other email title "server-to-client message? and a small
> patch. " patch there is not a bug but makes code less messy :)
>
> On 6/3/07, Jan-Klaas Kollhof <keyjaque@...> wrote:
> >
> >   Hey,
> >
> > thanks for the fix, it is checked in now.
> >
> > just checked trac, it did let me log in as guest/guest and it let me
> > create a ticket (#14). Not sure why it did not work for you.
> >
> > Jan
> >
> > --- In json-rpc@yahoogroups.com <json-rpc%40yahoogroups.com>, "Jorge
> > Vargas" <jorge.vargas@>
> >
> > wrote:
> > >
> > > Hi the bug tracker didn't let me post as guest/guest.
> > >
> > > there is a python error with the %-substitution. I believe what
> > you
> > > wanted is to be able to call module level functions. something
> > like
> > > this.
> > >
> > > {{{
> > > --- proxy.py (revision 16)
> > > +++ proxy.py (working copy)
> > > @@ -34,5 +36,5 @@
> > >
> > > def __getattr__(self, name):
> > > if self.__serviceName != None:
> > > - name = "%s.%s" % self.__serviceName
> > > + name = "%s.%s" % (self.__serviceName,name)
> > > return ServiceProxy(self.__serviceURL, name)
> > > }}}
> > >
> > > PS: I have made other changes to the file so the patch may not
> > apply cleanly.\
> > > PS2: it seems your trac instance needs some luv if you are
> > interested
> > > I can help getting it into shape (webadmin,account manager,
> > > milestones,versions,etc.
> > >
> >
> >
> >
>

WSGI ( http://www.python.org/dev/peps/pep-0333/ ) is increasingly
popular among the python web community.

I wrote a jsonrpc "application" that dispatches python methods over
jsonrpc. It's modeled somewhat after the XMLRPCDispatcher which is
part of the SimpleXMLRPCServer in python stdlib.

http://cheeseshop.python.org/pypi/wsgi_jsonrpc/
http://chandlerproject.org/Projects/WsgiJsonrpc

If you check out the source I also have a test client written that
functions like the python stdlib xmlrpclib.ServiceProxy, I believe
json-rpc.org might have also done a client like this bug it's been a
long time since I've looked.

-Mikeal

Hey,

thanks for the fix, it is checked in now.

just checked trac, it did let me log in as guest/guest and it let me
create a ticket (#14). Not sure why it did not work for you.

Jan



--- In json-rpc@yahoogroups.com, "Jorge Vargas" <jorge.vargas@...>
wrote:
>
> Hi the bug tracker didn't let me post as guest/guest.
>
> there is a python error with the %-substitution. I believe what
you
> wanted  is to be able to call module level functions. something
like
> this.
>
> {{{
> --- proxy.py    (revision 16)
> +++ proxy.py    (working copy)
> @@ -34,5 +36,5 @@
>
>      def __getattr__(self, name):
>          if self.__serviceName != None:
> -            name = "%s.%s" % self.__serviceName
> +            name = "%s.%s" % (self.__serviceName,name)
>          return ServiceProxy(self.__serviceURL, name)
> }}}
>
> PS: I have made other changes to the file so the patch may not
apply cleanly.\
> PS2: it seems your trac instance needs some luv if you are
interested
> I can help getting it into shape (webadmin,account manager,
> milestones,versions,etc.
>

Hi the bug tracker didn't let me post as guest/guest.

there is a python error with the %-substitution. I believe what you
wanted  is to be able to call module level functions. something like
this.

{{{
--- proxy.py    (revision 16)
+++ proxy.py    (working copy)
@@ -34,5 +36,5 @@

      def __getattr__(self, name):
          if self.__serviceName != None:
-            name = "%s.%s" % self.__serviceName
+            name = "%s.%s" % (self.__serviceName,name)
          return ServiceProxy(self.__serviceURL, name)
}}}

PS: I have made other changes to the file so the patch may not apply cleanly.\
PS2: it seems your trac instance needs some luv if you are interested
I can help getting it into shape (webadmin,account manager,
milestones,versions,etc.

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

I'm interested in the feature of server-to-client messages, specified
on the spec, but I can't find it's implementation on the python code,
is anyone working on it? if not I'll like to code it but I'll need
some guideline since I'm not sure how the blocking will be handle.

Also I have been playing around with the code and I think the
following patch is an improvement, the only part I'm not entirely sure
about is the empty string test as I think it's not a valid json
encoded object. I think this is too simple to open a ticket but if you
want to just let me know.

Index: _tests/test_json.py
===================================================================
--- _tests/test_json.py (revision 16)
+++ _tests/test_json.py (working copy)
@@ -87,6 +87,14 @@
          json = jsonrpc.dumps({'foobar':'spam', 'a':[1,2,3]})
          self.assertJSON(json, u'{"a":[1,2,3],"foobar":"spam"}')

+    def test_EmptyDictionary(self):
+        json = jsonrpc.dumps({})
+        self.assertJSON(json,u'{}')
+
+    def test_EmptyString(self):
+        json = jsonrpc.dumps('')
+        self.assertJSON(json,u'')
+
      def test_FailOther(self):
          self.failUnlessRaises(jsonrpc.JSONEncodeException,
lambda:jsonrpc.dumps(self))

Index: serviceHandler.py
===================================================================
--- serviceHandler.py (revision 16)
+++ serviceHandler.py (working copy)
@@ -55,23 +55,17 @@
              err = e
              req={'id':id_}

-        if err==None:
+        if not err:
              try:
                  id_ = req['id']
                  methName = req['method']
                  args = req['params']
-            except:
-                err = BadServiceRequest(json)
-
-        if err == None:
-            try:
                  meth = self.findServiceEndpoint(methName)
-            except Exception, e:
-                err = e
-
-        if err == None:
-            try:
                  result = self.invokeServiceEndpoint(meth, args)
+            except KeyError:
+                err = BadServiceRequest(json)
+            except ServiceMethodNotFound, e:#this could also be deleted
+                err = e
              except Exception, e:
                  err = e

@@ -110,4 +104,5 @@
              err = {"name": "JSONEncodeException", "message":"Result
Object Not Serializable"}
              data = dumps({"result":None, "id":id_,"error":err})

-        return data
\ No newline at end of file
+        return data
+
Index: proxy.py
===================================================================
--- proxy.py (revision 16)
+++ proxy.py (working copy)
@@ -20,12 +20,14 @@
  """

  import urllib
-from jsonrpc.json import dumps, loads
+from jsonrpc.json import dumps, loads, JSONDecodeException

  class JSONRPCException(Exception):
      def __init__(self, rpcError):
          Exception.__init__(self)
          self.error = rpcError
+    def __str__(self):
+        return self.error

  class ServiceProxy(object):
      def __init__(self, serviceURL, serviceName=None):
@@ -38,12 +40,14 @@
          return ServiceProxy(self.__serviceURL, name)

      def __call__(self, *args):
-         postdata = dumps({"method": self.__serviceName, 'params':
args, 'id':'jsonrpc'})
+         postdata = dumps({"method": self.__serviceName, 'params':
args, 'id':'jsonrpc'})
           respdata = urllib.urlopen(self.__serviceURL, postdata).read()
-         resp = loads(respdata)
+         try:
+             resp = loads(respdata)
+         except JSONDecodeException,e:
+             raise JSONRPCException(respdata)
+
           if resp['error'] != None:
               raise JSONRPCException(resp['error'])
           else:
               return resp['result']
-
-

hi,

> First, Is anything actually happening here?  I have seen no comments
> from the original draft authors in several months.  How can we get the
> ball rolling again?
I tried this, and created an improved working-draft (some months ago),
which you can find here: http://84.16.237.14/jsonrpc/

the next steps (for me) would be: maybe remove the mixed-parameters
again, solve the TODOs, and create a python-implementation.

> As a new reader of the spec, mixed named and positional arguments
> immediately jumped out as a glaring wart. Testing each argument name
> to see if it happens to be a number and reinterpret it accordingly is
> just gross, and opens the door to a range of possible implementation
> issues and ambiguities.
yes, that was really bad in the original 1.1WD.

in my draft, this is no longer a problem:
there are currently 2 alternatives:
1. the way it is currently described on http://84.16.237.14/jsonrpc/:
    "params" contains positional parameters,
    "kwparams" contains named parameters.
    having both in one call is possible, but discouraged, and may not
    be supported by all applications.

2. "params" may be an array or object;
    if it's an array, it only contains positional parameters;
    if it's an object, it only contains named parameters.
    mixing is not supported -- at least not by default.

    maybe I'll switch back to this (according to the poll),
    and modify http://84.16.237.14/jsonrpc/ the next days...

> More importantly, it goes against the stated
> philosophy of 1.1, which is that positional arguments are supported only
> for backwards-compatibility with 1.0 clients.
I think this "philosophy" is bad, since there are definitely some
applications which need positional parameters -- so I think they *are*
  important.


> Regarding error codes, someone expressed interest in what the XML-RPC
> community uses.  This is also evolving to some degree, but this is
> pretty much how things look at the moment in practice:
>
> > -32700 ---> parse error. not well formed
> > -32701 ---> parse error. unsupported encoding
> > -32702 ---> parse error. invalid character for encoding
> > -32600 ---> server error. invalid xml-rpc. not conforming to spec.
> > -32601 ---> server error. requested method not found
> > -32602 ---> server error. invalid method parameters
> > -32603 ---> server error. internal xml-rpc error
> > -32500 ---> application error
> > -32400 ---> system error
> > -32300 ---> transport error
> >
> > In addition, the range -32099 .. -32000, inclusive is reserved for
> > implementation defined server errors.
thanks. do you know where I can find the specification for this?
(because I didn't find any error-codes in the xml-rpc.)

regards,
Roland

Hi all,

I am a newcomer to the JSON-RPC 1.1 draft process.

First, Is anything actually happening here?  I have seen no comments
from the original draft authors in several months.  How can we get the
ball rolling again?

As a new reader of the spec, mixed named and positional arguments
immediately jumped out as a glaring wart.  Testing each argument name
to see if it happens to be a number and reinterpret it accordingly is
just gross, and opens the door to a range of possible implementation
issues and ambiguities.  More importantly, it goes against the stated
philosophy of 1.1, which is that positional arguments are supported only
for backwards-compatibility with 1.0 clients.  Also, I note that the
results of the recently-conducted poll showed 80% preference for
dropping
mixed arguments altogether.  I think this would make a whole generation
of future JSON-RPC implementors extremely grateful.

Regarding error codes, someone expressed interest in what the XML-RPC
community uses.  This is also evolving to some degree, but this is
pretty
much how things look at the moment in practice:

> -32700 ---> parse error. not well formed
> -32701 ---> parse error. unsupported encoding
> -32702 ---> parse error. invalid character for encoding
> -32600 ---> server error. invalid xml-rpc. not conforming to spec.
> -32601 ---> server error. requested method not found
> -32602 ---> server error. invalid method parameters
> -32603 ---> server error. internal xml-rpc error
> -32500 ---> application error
> -32400 ---> system error
> -32300 ---> transport error
>
> In addition, the range -32099 .. -32000, inclusive is reserved for
> implementation defined server errors. Server errors which do not
> cleanly
> map to a specific error defined by this spec should be assigned to a
> number in this range. This leaves the remainder of the space available
> for application defined errors.

If people aren't bothered by the large negative numbers, this seems
like a fine place for JSON-RPC to start.  Alternatively, if you want to
keep the three-digit-integer scheme, you could just take the last three
digits of each of these....

Matt

Matthew D. Hancher
Intelligent Systems Division
NASA Ames Research Center
Official: mdh@...
Personal: mdh@...

On May 7, 2007, at 6:26 AM, Jeffrey Damick wrote:

So the only bad thing is that by adding kwparams and removing the named arguments capability from params is that it is a pretty big change if you've already implemented 1.1WD and have it running in several environments (like me)..  This type of divergence from 1.1WD would prevent me (and probably others) from adopting it.  While i see the point about kwparams being more explicit than params, i think { vs. [ is just as easy to visually identify.  Maybe kwparams could only apply if you trying to mix them..

W

Hello,

I noticed that the specification has not yet specified error codes.  A
previous msg suggested using error codes found in XML-RPC
implementations.  Can anyone provide some links that contain lists of
these error codes?

Thanks,
Jon

On Mon, May 07, 2007 at 03:46:59PM -0000, Stephen M. McKamey wrote:
> (not to mention I think "kwparams" is an
> inelegant identifier that doesn't fit with the rest).
if you know a better name: tell me.

> I agree with Jeffrey: having just the one params object
> differentiated by type { vs [ would make more sense for me.
ok. but this would mean that you cannot mix named and positional
parameters. that would be ok for me, and I already suggested that
some time ago -- but since some people said they need this mixing,
I added kwparams...

> understood the need for mixing them anyway. It seems like an
> unneccessary complication to accommodate a very wierd usage.
here are some examples of RPC-calls with and without mixing:
(in python-syntax)

- with mixing:
sum(23,42)
sum(23,42, debug=False)
echo("test", times=10)

- without mixing, these would look like:
sum(23,42)
sum(23,42, False)
sum(s1=23, s2=42, debug=False)
echo("test", 10)
echo(content="test", times=10)

this i.e. means, that if you use parameters by-position, and want to add
a named parameter, you have to completely switch to named parameters.


so, if we don't need the "with-mixing"-sytax, we could again
drop kwparams, and always use params as array or object.
(but there **won't be mixed-parameters in params** like in 1.1WD!)

I created a poll for this.

regards,
Roland

Enter your vote today!  A new poll has been created for the
json-rpc group:

Do we need mixed named and positional parameters?
(this refers to the "suggestion for a simple JSON-RPC 1.1",
  http://84.16.237.14/jsonrpc/)

details:
- should something like "test(23,42, debug=False)" be possible?
   this would mean to "keep mixed parameters" and also keep kwparams.

- or is it ok to always write "test(23,42,False)" or "test(p1=23, p2=42,
debug=False)" instead?
   this would mean to "drop mixed parameters" and also drop kwparams.


   o keep mixed parameters
   o drop mixed parameters
   o undecided


To vote, please visit the following web page:
http://groups.yahoo.com/group/json-rpc/surveys?id=2197017

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.

Thanks!

I also have JSON-RPC 1.1 working and it works great. kwparams would
be a breaking change (not to mention I think "kwparams" is an
inelegant identifier that doesn't fit with the rest).

I agree with Jeffrey: having just the one params object
differentiated by type { vs [ would make more sense for me.  I never
understood the need for mixing them anyway. It seems like an
unneccessary complication to accommodate a very wierd usage.

--- In json-rpc@yahoogroups.com, "Jeffrey Damick" <jeffreydamick@...>
wrote:
>
> So the only bad thing is that by adding kwparams and removing the
named
> arguments capability from params is that it is a pretty big change
if you've
> already implemented 1.1WD and have it running in several
environments (like
> me)..  This type of divergence from 1.1WD would prevent me (and
probably
> others) from adopting it.  While i see the point about kwparams
being more
> explicit than params, i think { vs. [ is just as easy to visually
identify.
> Maybe kwparams could only apply if you trying to mix them..
>
>
> -jeff

On Sun, May 06, 2007 at 03:30:53AM -0000, jimcburg wrote:
> I'm guessing that you are just checking whether people are actually
> reading the thing, but you have "params" identified with "by-name" and
> "kwparams" identified with "by-position".
oh, thanks. it's corrected now.

> Presuming that "Extensions" are optional,
yes, they are optional.

> Overall, except a few minor edits, I give your recommendation a +1.
thanks :).

regards,
Roland