<div dir="ltr">zip is used in reltool for making compressed code archives. gzip is used in a number of places, including term_to_binary with compression. I think the previous posters' points still stand.<div><br></div><div>I think the proper path for JSON into the standard library is the way many other language communities have done it. Let competing implementations start as a third-party libraries, and then if (and only if) there is enough momentum and pressure around a single candidate take steps to include it. The main challenge I see for any of this happening with Erlang/OTP is that getting patches accepted is difficult enough already, and every one of the existing JSON libraries uses a slightly different style. It's probably best as third party library.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 7, 2015 at 7:23 AM, Éric Pailleau <span dir="ltr"><<a href="mailto:eric.pailleau@wanadoo.fr" target="_blank">eric.pailleau@wanadoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
I agree but there is some lack however, zip/gzip exists in Otp, but not bzip nor lzma2.<br>
As it is ports, it should be done at core level while json can be external libraries.<br>
Those compressions formats are now very common in particular lzma2. Really missing.<br>
Regards<br>
<div class="HOEnZb"><div class="h5"><br>
Le 7 sept. 2015 09:39, Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> a écrit :<br>
><br>
> On 09/07/2015 03:34 AM, Theepan wrote:<br>
> > Team,<br>
> ><br>
> > Is there any reason why a JSON library is not included into Erlang/OTP<br>
> > releases? Since it was initially planned for telco systems, it includes<br>
> > ASN.1 library. It has some other transfer-format libraries as well.<br>
><br>
> ASN.1 isn't just a "transfer-format", it's something OTP itself *uses*.<br>
> Without the ASN.1 application, there would be no public_key application,<br>
> and therefore no SSL, to name one.<br>
><br>
> JSON would be just sitting there. What's the point?<br>
><br>
> Another argument against it is one you cited in your email: there are<br>
> already a variety of open source JSON libraries. Each has different<br>
> properties and are useful to different people. Why would you include one<br>
> and basically doom the others? Which one would you bundle? Will that<br>
> choice make sense to everyone?<br>
><br>
> Finally, I'm not sure what's the point? If you are using Erlang.mk, to<br>
> use jsx, you need to add this single line to your Makefile:<br>
><br>
> DEPS = jsx<br>
><br>
> If jsx was part of OTP, you would need to add this single line to your<br>
> Makefile:<br>
><br>
> OTP_DEPS = jsx<br>
><br>
> The advantage of bundling it in OTP are not obvious, to say the least.<br>
><br>
> In general I believe OTP should reduce the number of libraries it comes<br>
> with, not increase it. It's easy to find a library fitting your needs<br>
> nowadays. Erlang.mk for example has 470 packages and you can search them<br>
> in one easy command: make search q=json<br>
><br>
> Cheers,<br>
><br>
> --<br>
> Loïc Hoguin<br>
> <a href="http://ninenines.eu" rel="noreferrer" target="_blank">http://ninenines.eu</a><br>
> Author of The Erlanger Playbook,<br>
> A book about software development using Erlang<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>