[erlang-questions] json_to_term EEP
Wed Jul 30 08:57:24 CEST 2008
In message <5B5B0B86-D10A-4B88-AA77-BD13381E1393@REDACTED>
Richard O'Keefe writes:
>On 29 Jul 2008, at 6:10 pm, Willem de Jong wrote:
>> How about a SAX-like API?
>(1) Anyone who wants such a design can produce their own design,
> AND their own code. The EEP I am concerned with is a DVM-
> like design (Document *Value* Model).
Note: if anyone dislikes DVM because of difficulties
in editing large values - have a look at "zippers".
>(5) The JSON-RPC 1.1 draft (I haven't looked at 1.0) hints at some
> kind of ESIS/SAX-like interface when it says that arguments
> should be sent in such an order that the receiver can process
> them when it gets them. How are people actually using JSON-RPC?
> Is there that much to gain, in actual practice?
I've used only JSON-RPC 1.0, which (as gratuitous exposition) was
requests are JSON objects with the fields:
- id: (term) a value to associate request and response
- method: (string) the name of the procedure being called
- args: (array) the arguments
responses are JSON ojects with the fields:
- id: (term) to associate the response with the request
- result: (term) the result of the procedure application
- error: (term) an exceptional result
- exactly one of result or error will be null
JSON-RPC could be layered directly over TCP, or any other bytestream
transport. This means that the JSON parser is required to do proper
framing - to be able to handle too much or too little input. This
motivated my request for a continuation-based parser interface in
my feedback to the original EEP draft.
The direct layering of JSON-RPC over a stream transport allowed for
out-of-order responses over a single connection. For reasonably-sized
requests and responses, this was almost as good as having channels
within the connection, as BEEP has. Sadly, JSON-RPC 1.1 looks like
it is only layered on top of HTTP, losing this feature.
In answer to your question, I've used JSON-RPC (1.0) for a production
service, and I've been just fine with a value model for the parsed
results. I kept the size of JSON terms small by design: if the
parsed terms were too big to conveniently handle as Erlang values,
they would have been clogging the transport too much.
More information about the erlang-questions