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:
|
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 |
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. |