When is the json body of a request ready for parsing?

[Joe Bob]

Or -- as an implementer do I need to track { and }?  or is there some end of request token I'm missing in the spec?

[Skylos]

I would hope as an implementer you're already using a stream-capable json parsing engine, because, after all, who needs the noise of implementing THAT wheel yet again. In which case, your stream-capable json parsing engine will emit an event or initiate a callback at such a time that you could react to.

But if you need to implement such an engine to enable your app... alright, its simple enough I guess, and yes, you'll effectively be 'tracking' your token events. Get some comprehensive tests wrapped around it though.

On Wed, Oct 9, 2019 at 7:39 PM Joe Bob <eric.h...@gmail.com> wrote:

Or -- as an implementer do I need to track { and }?  or is there some end of request token I'm missing in the spec?

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-rpc+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/json-rpc/836442dd-ebb9-4d6f-b223-3fcd29a79341%40googlegroups.com.

--

Dog approved this message.

[Joe Bob]

Makes perfect sense.. thanks..:)    Our current parser isn't that cool; and I don't look forward to debugging my own.  Time to find a new parser. :)

-Eric

On Wednesday, 9 October 2019 21:07:38 UTC-7, DavidIAm wrote:

I would hope as an implementer you're already using a stream-capable json parsing engine, because, after all, who needs the noise of implementing THAT wheel yet again. In which case, your stream-capable json parsing engine will emit an event or initiate a callback at such a time that you could react to.

But if you need to implement such an engine to enable your app... alright, its simple enough I guess, and yes, you'll effectively be 'tracking' your token events. Get some comprehensive tests wrapped around it though.

On Wed, Oct 9, 2019 at 7:39 PM Joe Bob <eric....@gmail.com> wrote:

Or -- as an implementer do I need to track { and }?  or is there some end of request token I'm missing in the spec?

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to json...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/json-rpc/836442dd-ebb9-4d6f-b223-3fcd29a79341%40googlegroups.com.

[Nathan Fischer]

Are you just using a straight TCP socket as a transport?

[Joe Bob]

It will be a TCP, or unix domain socket.  With Go on one side and Rust on the other.   

[Nathan Fischer]

 Gotcha.

Well if you can't find a good streaming parser in those languages, you might strongly consider adding some simple length prefix message framing on top of TCP.

Many people use websockets for this purpose, but something as simple as sending an unsigned integer with the length before the message is lightweight and really simplifies implementation compared to writing a streaming json parser.

[Joe Bob]

Yeah... actually our first few attempt to find a streaming parser haven't turned up much.  Which surprised me enough that I don't think we're looking hard enough.  :)    Given the nature of json-rpc being a ASCII protocol we were thinking of just saying:

1) our json won't be pretty (we'll actively enforce this)

2) each request/response will have a newline on the end

If that doesn't work out (maybe we want pretty json over the wire!  :)  )  We'll go with prefixing it with a size.

The newline method is appealing because of the simplicity of implementation. 

[Nathan Fischer]

Some thoughts on that

• You might consider using null to terminate your message instead of new line. Then you can have pretty json, and more importantly an implementation sending valid json won't have the ability to break things.
• JSON is actually UTF rather than ASCII, so make sure you're not assuming that it's one character per byte.
• Look into efficient data structures like a rope since without the length prefix you won't be able to allocate a single block of memory for up front. A rope lets you append many arrays together as they come compared to the inefficient behavior of a vector which would be constantly allocating bigger and bigger arrays and de-allocating the old ones.
  

[Joe Bob]

I appreciate the ideas.  I hadn't heard of that data-structure referred to as rope before.  When I said ASCII -- I should have said "non-binary".   For now we're going with a  simple to implement approach.  This will be a very low traffic connection.  RPC calls will be on the order of 1 per day.   Resisting the urge to prematurely optimize and make a magnificent json-rpc handler...:) 

-Eric