09:20
<nicolo-ribaudo>
styfle guybedford The "JSON modules" proposal is stage 4 and part of ecma-262, there is no need for the import bytes proposal to "build o top of it"
09:21
<nicolo-ribaudo>
styfle Can you link to https://styfle.github.io/proposal-import-buffer/ in the repo metadata?
09:24
<nicolo-ribaudo>

Two questions also:

  • Why does CreateBufferModule accept a SharedArrayBuffer? If implementations don't want a mutable ArrayBuffer, a SharedArrayBuffer seems even worse
  • I missed when we switched from Uint8Array to ArrayBuffer. Why that change? Every API that accepts an ArrayBuffer also accepts a Uint8Array anyway, but Uint8Array avoid the "conversion step" for the most common use cases of needing the bytes.
09:26
<nicolo-ribaudo>
Editorially speaking, I think it would be better to say in HostLoadImportedModule "must perform FinishLoadingImportedModule(referrer, moduleRequest, payload, result), where result is either the Completion Record returned by an invokation of CreateDefaultExportSyntheticModule with an immutable ArrayBuffer parameter or a throw completion" without needing the new CreateBufferModule AO, but the current approach is also fine
09:31
<nicolo-ribaudo>
Note that https://github.com/styfle/proposal-import-buffer/issues/5 was asking for the backing ArrayBuffer of the Uint8Array to be an immutable ArrayBuffer, not for the Uint8Array to be replaced with an immutable ArrayBuffer
09:32
<nicolo-ribaudo>
Oh, I see, https://github.com/styfle/proposal-import-buffer/issues/5#issuecomment-3059482682. I'll bring it up in plenary
09:47
<bakkot>
w3c guidelines say to use Uint8Array for sequences of bytes https://www.w3.org/TR/design-principles/#uint8array
09:47
<bakkot>
(disclosure: I wrote this rule)
09:48
<nicolo-ribaudo>
Oh thank you
09:49
<bakkot>
the Response type has a bytes method for getting a Uint8Array as well as a now-considered-mistake arrayBuffer method for getting an ArrayBuffer and json for getting json and text for getting text
09:49
<bakkot>
whichever type we chose I think the names should match
09:49
<nicolo-ribaudo>
Do you know if there is any API that accepts array buffers but not uint8arrays?
09:49
<bakkot>
so if we do ArrayBuffer it should be with { type: "arrayBuffer" }
09:50
<bakkot>
well, the TypedArray constructors
09:50
<bakkot>
otherwise, no, everything on the web uses ArrayBufferView
09:51
<nicolo-ribaudo>
Ok yeah -- for typed array constructor it's probably fine since they are a "conversion step" anyway so adding the .buffer is not annoying
09:53
<bakkot>
I might be OK with having both type: "arrayBuffer" and type: "bytes" I guess, if people strongly want to be able to get a non-wrapped ArrayBuffer
09:53
<bakkot>
but my preference would also be just bytes for a Uint8Array
09:54
<bakkot>
web platform is probably not going to put .arrayBuffer() when adding this set of methods to new types, see thread starting at https://github.com/whatwg/streams/issues/1019#issuecomment-3014862880
12:02
<annevk>
Yeah, let's only expose bytes as Uint8Array going forward pretty please
12:02
<annevk>
I think on the consumption side it makes sense to be lenient, but not when producing
12:04
<annevk>
Note that we are strict on the consumption side if it's an output parameter, as with encodeInto(), and again I think that makes sense
13:35
<styfle>
The proposal was originally written as bytes and then changed to buffer based on all the feedback in issue https://github.com/styfle/proposal-import-buffer/issues/5
13:37
<styfle>
guybedford: guybedford (Guy Bedford) We might ave a typo in the spec. Can you take another look?
13:44
<annevk>
styfle: that seems exactly like the kind of thing that ought to use Uint8Array.
13:46
<annevk>
And that discussion is mainly about mutability, which is really about the underlying buffer.
13:49
<nicolo-ribaudo>
Let's see how the discussion goes today in plenary, I suspect that most will want the Uint8Array
13:49
<nicolo-ribaudo>
@annevk:matrix.org I can mention that it's also your preference
15:37
<kriskowal>
I personally like the spelling of type bytes, like that it aligns with the fetch api, and buy the argument that if it’s called bytes, the representation should be uint8array (backed by immutable arraybuffer). If the representation is a bare arraybuffer, I prefer the spelling type: buffer. I don’t love having both but I don’t mind. Agoric will make the case for “buffer” ArrayBuffer today, but I will support any of the above options (bytes, buffer, or both) but insist on immutable backing arraybuffer.
15:52
<bakkot>
I feel reasonably strongly that if we have a bare ArrayBuffer it must be named arrayBuffer to match the rest of the web platform (and to avoid being confusing on Node and similar runtimes, which have a widely used typed named Buffer which is basically Uint8Array).
15:54
<kriskowal>
I feel reasonably strongly that if we have a bare ArrayBuffer it must be named arrayBuffer to match the rest of the web platform (and to avoid being confusing on Node and similar runtimes, which have a widely used typed named Buffer which is basically Uint8Array).
Alright, I can bend to that.
15:55
<annevk>
Though bare ArrayBuffer seems a bit silly at this point.
17:10
<Mathieu Hofman>
To clarify, the request from Agoric was for immutable ArrayBuffer backing. We are fine with import bytes being a Uint8Array, as long as the backing buffer is immutable.