[cl-json-devel] Question about NIL translation

[Robert Goldman]

On 1/6/10 Jan 6 -7:46 AM, Robert P. Goldman wrote:
> I have most of a patch for providing JSON-RPC 2.0 support. I will try  
> to submit it by the end of the week.
> 
> What about a json-rpc type of :Boolean? This would take the raw output  
> of the cl function and turn it into true or false according to cl  
> rules. We could also have a type of :array as alternative, that would  
> turn any sequence into a json array and would turn NIL into []  
> (singleton return values would signal an error).

A quick follow-up:  would it be acceptable to create a generic function
like this:

(defgeneric encode-json-rpc-value (keyword value)
   (:documentation "An extensible set of methods for encoding
JSON-RPC values according to a keyword specification")
   (:method (keyword value)
       (declare (ignore value))
       (error "Keyword ~a does not correspond to any JSON-RPC encoding"
             keyword))
   (:method ((keyword (eql :guessing) value)
     ....))

and use this to replace the ecase in INVOKE-RPC-PARSED ?

That would make it easier for people to come up with their own encoding
schemes.

If you like, I will try to supply a patch.

best,
r

> 
> Just a thought; haven't considered the implications deeply...
> 
> On Jan 6, 2010, at 7:10, Henrik Hjelte <henrik at evahjelte.com> wrote:
> 
>>> 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
> 
> _______________________________________________
> cl-json-devel mailing list
> cl-json-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cl-json-devel