On Thu, Dec 31, 2009 at 11:17 PM, Robert Goldman rpgoldman@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