Redundant APIs for Encoding/Decoding

[ldclakmal]

Description:
Some of the APIs related to the functionalities of encoding/decoding was introduced to langlib/array recently [1]. Those functionalities were already supported and used since Ballerina v0.991.0 with ballerina/encoding module [2]. So, now there are redundant APIs in both langlib/array and ballerina/encoding module.

Newly introduced APIs in langlib/array module

public function toBase64(byte[] arr) returns string = external;
public function fromBase64(string str) returns byte[]|error = external;
public function toBase16(byte[] arr) returns string = external;
public function fromBase16(string str) returns byte[]|error = external;

Matching APIs in the ballerina/encoding module

public function encodeBase64(byte[] input) returns string = external;
public function decodeBase64(string input) returns byte[]|Error = external;
public function encodeHex(byte[] input) returns string = external;
public function decodeHex(string input) returns byte[]|Error = external;

The issue is that what should be done for the rest of the APIs, which were given under the ballerina/encoding module?

Also, where should we add the newly introduced APIs for encoding/decoding in the future?

[1] https://github.com/ballerina-platform/ballerina-lang/blob/master/langlib/lang.array/src/main/ballerina/src/lang.array/array.bal#L204
[2] https://github.com/ballerina-platform/ballerina-lang/blob/master/stdlib/encoding/src/main/ballerina/src/encoding/encoding.bal

Related discussion: https://groups.google.com/d/msg/ballerina-dev/sbASEwIl44k/0YlP3IcXFwAJ

[jclark]

There is also toBytes and fromBytes in lang.string.

It looks like the remaining things in encoding are:

• conversion to and from base64 URL; I guess this is https://tools.ietf.org/html/rfc4648#section-5
• conversion to and from named text encodings (other than UTF-8)

The 2nd, in my view, is legacy at this point, and pulls in a lot of code, so should be a separate module, with a richer API (e.g. enumerate the available encodings etc). Eventually we will need a bunch of Unicode/i18n libraries, and I would include that there.

Not sure about the first. Maybe put it together with URL-related stuff.

[sanjiva]

We don't have a URL specific place right now, but yeah +1 for removing the methods from the encoding module and maybe leaving just the URL encode/decode function there for now.

I don't know whether we have time to change the code for this release. Worst case we can leave these in encoding and remove later (as the usage is internal to stdlibs).

And +1 to removing non-UTF-8 from basic libs and doing them (later) as another module.