[erlang-questions] json_to_term EEP

[Jim Larson]

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
essentially just:

	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.

Jim