[cl-json-devel] Question about NIL translation

[Robert Goldman]

On 1/1/10 Jan 1 -10:36 AM, Henrik Hjelte wrote:
> On Thu, Dec 31, 2009 at 11:17 PM, Robert Goldman <rpgoldman at sift.info> wrote:
>> Continuing to work on my CL-JSON based JSON-RPC server, I am concerned
>> about the fact that we translate NIL -> null.
>>
>> If a CL function returns NIL, and the return value is simply encoded
>> into the JSON return package, then we get a message that /should/
>> indicate an error, according to the JSON-RPC server.
>>
>> In fact, if our CL function is invoked by JSON-RPC, then we really
>> should have NIL either encoded as [] or as false, but /never/ as null.
>>
>> Any ideas about how we should modify invoke-rpc-parsed to fix this?
>>
>> What is the right way to tell CL-JSON to encode a false?
> 
> Cl-json currently has three encoders. Traditionally the most used and
> the one used in json-rpc is the guessing encoder (see testcases for
> documentation). It is not very good if you want fine-grained control,
> then I'd say that the explicit encoder I recently added is more
> convenient. Another alternative is the streaming encoder. With the
> explicit encode json false is (false)
> 
> To fix this, I'd probably add an option to (or even recode) json-rpc
> to use the explicit-encoder instead. Preferably backwards compatible
> so code that uses json-rpc and uses the guessing-encoder doesn't
> break. Maybe a function called defun-json-rpc-explicit? The backward
> compatiblity could be preserved by encoding the old defun-json-rpc
> using the guessing encoder, then passing it as a json-string to the
> explicit encoder using the (json "some json string") format. I think
> this sounds more job than it is, it should not be very difficult.
>

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?

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.

Best,
r