JSON in OTP

[Kenneth Lundin]

The answer is that looking back maybe we should have added JSON
encode/decode to OTP 12 years ago, but now there are a number of good
separate JSON libraries
outside OTP so why should we (the OTP team) take on the task of developing
and maintaining a JSON library.
Why is it better to include the JSON lib in OTP than to have it separate?
We have:
jsx, jsone, jiffy, .... to name a few

We or someone else could create an OTP+ distribution which includes OTP +
other popular non OTP applications. I even think Erlang Solutions has done
that at some point.

/Kenneth, Erlang/OTP, Ericsson

On Mon, Nov 2, 2020 at 10:39 PM Viktor Söderqvist <viktor@REDACTED>
wrote:

> 12 years have passed since EEP 18. [1] Since then, maps have been added
> to Erlang and the string module has been made accept binaries. This
> makes up a more obvious representation of JSON than in 2005 [2].
>
> If anyone was arguing that OTP is made for telecom and not web
> development, this argument doesn't hold anymore, now that the telecom
> standards are replacing GTP and Diameter with HTTP and JSON.
>
> The 5G mobile network specifications are full of JSON, REST and HTTP/2
> (e.g. 3GPP TS 29.500 [3]) and in 3GPP TS 29.501 [4] things like
> HATEOAS, OpenAPI specifications using JSON Schema and YAML files and
> how JSON documents should be patched using HTTP PATCH requests are
> covered. (Other interesting 5G specs are 23.501 [5] and 23.502 [6].)
>
> JSON has also been standardized as ECMA-404 [7] in 2017.
>
> Is it time to re-evaluate adding json:{encode,decode}/1 in OTP? Or are
> the arguments against it still valid?
>
> Regards,
> Viktor
>
> [1]: http://erlang.org/eeps/eep-0018.html
> [2]:
> http://erlang.org/pipermail/erlang-questions/2005-November/017805.html
> [3]: https://www.3gpp.org/DynaReport/29500.htm (Click the Versions tab,
> then click a linked version number to download a zip file which
> contains a Word document, which can be converted to a readable
> format...)
> [4]: https://www.3gpp.org/DynaReport/29501.htm
> [5]: https://www.3gpp.org/DynaReport/23501.htm
> [6]: https://www.3gpp.org/DynaReport/23502.htm
> [7]:
> http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201104/84fe4ba3/attachment.htm>