What about making the type argument to defun-json-rpc optional instead of mandatory. If the default is explicit encoding then we'd still have backward compatibility without adding a new, more verbose-named defun?
yes, good idea. I had actually forgotten I had added some support for different encoders in json-rpc.
I think the reason I don't had the type argument optional is because I am a weak coder, I just don't know how to make type &optional in the right way. I guess you can put all three type lambda-list and body as one &rest and parse it. On the other hand: I personally don't have a strong problem with breaking backwards compatibilty in this way, it is only for a small subset of cl-json and it breaks you old code in an "nice" way, throwing an error that is easy to fix.
(defmacro defun-json-rpc (name type lambda-list &body body)
The CL-JSON spec for 1.1 seems like a real mess --- it's not at all clear what should happen if you invoke a method over CL-JSON that returns a null value (e.g., a JS function with no return).
The 2.0 (draft) spec seems to have a much clearer approach to this....
I'm inclined to just move to observing the draft 2.0 spec.
Yes why not? I am not aware of the exact differences, except that 2.0 has named parameters.
Maybe it is possible to expose a function both as 1.1 and 2.0?
/Henrik