DataType vs mime type vs encoding

[rpaquay]

We seem to be keep running into issue with the way we read and write files wrt to the "DataType" usage.

For example, jsfs always returns DataType.Value when reading files, even though they were saving with a different datatype. It begs the question of why we have a optional data type on the FileSystem.readFile function. What is the purpose?

Another issue is the GDrive file system. GDrive stores a mime type for every file, and allows specifying a "conversion" mime type when reading sheets or docs. Should we include this level abstraction into the Axiom API. How?

A proposal would be to generalize DataType to mimeType as follows:

writeFile(path, mimeType, data)

• path is the file path (as usual)
• mimeType is the mime type of the file
• data is either a string (for text mime type) or an ArrayBuffer for all other types.
• If mimeType is text, use the charset:encoding of mimeType to figure out the encoding.

readFile(path, mimeType)

• path is the file path (as usual)
• mimeType is optional and defines the mime type of the stored data. The file system uses mimeType encoding part as a for decoding stored text as a JavaScript string.
• The return value is either a string (if mimeType is string) or an ArrayBuffer.

[ussuri]

Yes, that looks logical to me.

[gaurave]

👍