[cl-json-devel] Question about NIL translation

[Henrik Hjelte]

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.

/Henrik