Add return_truncated decode flag #158
Conversation
There was a problem hiding this comment.
The implementation looks great but I'm wondering what the use case is exactly? Is this to detect where there's broken JSON or something? Also not entirely certain it needs to be an option seeing as we could just make it the default. I've got two or three other breaking changes I'd like to make as well and then finally call it a 1.0 I'd be fine adding this to that list rather than making it an option if that seems more logical.
c_src/decoder.c
Outdated
| @@ -1035,7 +1039,11 @@ decode_iter(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) | |||
| } | |||
|
|
|||
| if(dec_curr(d) != st_done) { | |||
| ret = dec_error(d, "truncated_json"); | |||
| if (d->return_truncated) | |||
There was a problem hiding this comment.
You need to add braces around the bodies of this if/else statement.
|
The use case is that I have a protocol which takes JSON over streaming sockets (TCP, websocket). JSON is basically the "framing" format. Because of the properties of the protocol, you can get partial frames. In that case, I know to go ahead and wait for more and add it to the buffer before trying to decode again. I know that JSX has a streaming API, but I personally find it really difficult to use, especially when my messages are <16KB. A simple decode, append, continue loop works just fine. |
|
That makes sense but with the return_trailer and existing trucated
exception I’m not seeing what the extra position is giving. Seems like it’d
always be the end of the binary no?
…On Wed, Nov 22, 2017 at 4:16 PM Sargun Dhillon ***@***.***> wrote:
The use case is that I have a protocol which takes JSON over streaming
sockets (TCP, websocket). JSON is basically the "framing" format. Because
of the properties of the protocol, you can get partial frames. In that
case, I know to go ahead and wait for more and add it to the buffer before
trying to decode again.
I know that JSX has a streaming API, but I personally find it really
difficult to use, especially when my messages are <16KB. A simple decode,
append, continue loop works just fine.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#158 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABN2Usdu-86vmbHTaKXkW2jrdWDMeCPks5s5J01gaJpZM4QnIKW>
.
|
|
Yeah, I'd think so, the only reason I'm returning the extra position is because I wanted it to be as similar to the existing API mechanism as possible. I agree, it doesn't make a lot of sense, but I'd hate to break API backwards compatibility. |
sargun
force-pushed
the
return-on-truncated
branch
from
eac9574 to
66797a9
Compare
|
Fixed the braces. |
|
How do you want to proceed? |
No description provided.