Consider a byte[] primitive.

[crdrost]

At least in the HTTP context which I am expecting to build up, a byte array primitive would make some sense if we had some sort of "upload a file with multer" experience lined up. It's also helpful in crypto APIs like nermal.

Challenges:

• If this framework applies to frontends it cannot reference Buffer explicitly, so that leaves UInt8Array, is that acceptable?
• Does deno have a third mutually inconsistent byte[] type?
• Do I even really want to do this given that at USEng generally the file is some 200+MB PDF or 100MB gzip file containing gigs of JSON? Reading those straight into memory is a Bad Idea, you really want to pass everything through a stream, and a stream just requires a file path which is a string which is a text.

[crdrost]

deno uses a buffer which wraps a Uint8Array. Node has everything we need to convert Buffers to and from Uint8Arrays and it's the only standard option for intercompatibility. So if we're doing this it has to go that way.

[crdrost]

I am thinking that if a string deserialization is needed we might just standardize url-safe base64 for that?

The primary problem there is that base64 implementations for NodeJS usually use Buffers and are therefore not portable to the browser, whereas tasso right now doesn't care. URL-safe is important because one of my primary goals for Tasso is to embed things in URLs but there would be a reason to allow interoperability maybe. Consider maybe something like:

let s = str.replace(/[-_]/g, s => s ==='-'? '+' : '/');
while (s.length % 4 !== 0) {
  s += '=';
}
return {type: 'ok', value: new UIntArray(atob([...s].map(s => s.charCodeAt(0))}

which should be built into JS directly with no external dependencies. Maybe also a regex to validate that the input is well-formed?