-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Agree on handling of JSON value types #52
Comments
Copying my comment from there: OK, you're right, the RFC is explicit: "JSON text is a serialized object or array" http://www.ietf.org/rfc/rfc4627.txt By contrast, the ECMA spec permits any text that satisfies the grammar for a JSON value (which does include primitives): http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf So I agree remove support for primitives. |
Ok, so do we explicitly reject data that is not a supported type, or allow it but then let the developer deal with the possible crash on the other end. I think we should explicitly reject unsupported types so that we can guarantee type portability between all client libraries. |
Yes, on balance I think it should be rejected. |
.. but then there is the issue of how we claim to police the supplied values. For example, NaN can't be represented in JSON - so do we check for those as well? |
Nope, I think it is acceptable that we support String, Binary (ByteArray), and JSON Array / Objects. If you have a value in there that the native serialiser accepts, such as NaN becoming |
ok, agreed |
Please see ably/ably-ruby#48 where I have implemented this |
Creating this issue to cover the discussion at #51
Probably better if we continue the discussion here as an issue
The text was updated successfully, but these errors were encountered: