On 12/30/09 Dec 30 -12:50 PM, Henrik Hjelte wrote:
On Wed, Dec 30, 2009 at 4:37 PM, Robert Goldman <rpgoldman@sift.info> wrote:
I am setting up a JSON-RPC server over sockets, rather than HTTP, and have a couple of questions about json-rpc.lisp:
1. Am I correct in thinking that INVOKE-JSON does not handle notifications? It looks like it will always try to return a result. Question: would it be reasonable to modify INVOKE-JSON to handle notifications by just executing the function and /not/ returning a result?
Yes, but how would the API change. An idea is to let the caller decide if he wants return values, maybe by exposing two functions.
If I understand the CL-JSON spec correctly, the caller decides that s/he doesn't want return values by setting the ID field of the request to null. My modified invoke-json function checks for a null id field and returns nothing if it finds that.
2. My socket server must parse JSON messages and decide what type they are before it can call invoke-json. This suggests refactoring invoke-json into two stages:
a. the part that calls the decoder and pulls out the three slots
b. an inside function that accepts method, params, id, and does the actual invoking.
I was thinking of submitting a patch along those lines. Please let me know if that seems wrong.
I agree with the problem.
OK, if this seems like a reasonable refactoring, I will grapple with darcs and try to get it to yield me a patch to send you. Best, R